From anca at opensips.org  Sun Feb  1 00:44:14 2009
From: anca at opensips.org (anca)
Date: Sun, 01 Feb 2009 01:44:14 +0200
Subject: [OpenSIPS-Devel] [NEW] Memory Cache (memche) support in OpenSIPS
	1.5.0
Message-ID: <4984E24E.4090802@opensips.org>

Hello,

As part of a large effort to reduce the negative impact of the DB 
queries in the OpenSIPS performance, OpenSIPS 1.5.0 has now support for 
Memory Cache (memcache). As said, this is just a part of the effort of 
optimizing the DB interfacing (part of this work is the upcoming support 
for prepared statements in DB queries).

The Memory Caching support from OpenSIPS wants to provide a way of 
caching at runtime different kind of data. These data will globally 
available (anywhere in the routing script) and shared between all 
OpenSIPS processes.

The idea is to be able to store (cache) custom values for later usage. 
The main purpose of this MemCache support is to reduce the number of DB 
queries by caching data that does not need constant update from DB. DB 
queries are known to be one of bottle necks in the current design (see 
design considerations - 
http://www.opensips.org/index.php?n=Development.NewDesign) and MemCache 
support will help in avoiding unnecessary DB hits.

To find out more about the design, implementation and usage examples for 
Memory Caching, see MemCache Tutorial from the web site:
   http://www.opensips.org/index.php?n=Resources.DocsTutMemcache


From noreply at sourceforge.net  Sun Feb  1 17:41:28 2009
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun, 01 Feb 2009 16:41:28 +0000
Subject: [OpenSIPS-Devel] [ opensips-Bugs-2538399 ] Bug in presence when
	using fallback2db
Message-ID: <E1LTfNw-0000MU-PR@665xhf1.ch3.sourceforge.com>

Bugs item #2538399, was opened at 2009-01-26 14:39
Message generated for change (Comment added) made by oren_k
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=2538399&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: Oren K (oren_k)
Assigned to: Anca Vamanu (anca_vamanu)
Summary: Bug in presence when using fallback2db

Initial Comment:
Hi,

While using the presence module, I run this scenario:

a. user1 SUBSCRIBE's to presence of user2
(subscription is now pending)

b. user2 allows user1 in pres-rules
(refreshWatchers is called, subscription is now active. user1 receives a NOTIFY from presence server with user2's current tuple and Subscription-State: active)

c. user2 PUBLISH'es a new presence tuple
-- at this point presence server should NOTIFY user1 of the new presence but it doesn't (that's the bug).


My modparams:

modparam("presence|presence_xml", "db_url", "mysql://root at localhost/opensips")

modparam("presence", "server_address", "sip:presence.example.com:10500")

modparam("presence", "fallback2db", 1)
modparam("presence", "clean_period", 30)


What I see in the debug trace is that get_subs_dialog (from notify.c) can't find any dialogs in the database, and all those in the subs hash are flagged NO_UPDATEDB_FLAG. This is probably what's causing the problem. 
Strangely, in the above scenario if user1 un-SUBSCRIBEs and re-SUBSCRIBEs to user2's presence - it does receive notifications.

Regards,
Oren K.

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

Comment By: Oren K (oren_k)
Date: 2009-02-01 11:41

Message:
Sorry I forgot to login, that comment is from me :)

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

Comment By: Nobody/Anonymous (nobody)
Date: 2009-01-28 10:12

Message:
Thanks for the reply anca. Version is opensips-1.4.4-tls, compiled from the
sources with TLS="1". 

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

Comment By: Anca Vamanu (anca_vamanu)
Date: 2009-01-28 06:48

Message:
Hi Oren,

What OpenSIPS version are you using? Trunk or stable release?

regards,
Anca

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

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


From noreply at sourceforge.net  Mon Feb  2 10:04:36 2009
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 02 Feb 2009 09:04:36 +0000
Subject: [OpenSIPS-Devel] [ opensips-Bugs-2430807 ] Opensips crashes when
	publish received for RLS list
Message-ID: <E1LTujM-0002xY-Un@565xhf1.ch3.sourceforge.com>

Bugs item #2430807, was opened at 2008-12-15 16:34
Message generated for change (Comment added) made by rmnathan
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=2430807&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: 8
Private: No
Submitted By: Nathan (rmnathan)
Assigned to: Anca Vamanu (anca_vamanu)
Summary: Opensips crashes when publish received for RLS list

Initial Comment:
Version - trunk(5049)
I have tried all sort of following thing to generate core . But it failed to generate core dump.
1.  disable_core_dump is set to no
2. set fork=no and child=no
3. tried to find core dump  at /
4. compiled opensips with the following command
    make mode=debug modules
    echo $?
    make mode=debug prefix=/usr/local/ install
5. OS stinbng46:/# uname -a
Linux stinbng46 2.6.18-staros-v2-20294-deb #1 SMP Mon Jul 14 05:18:18 EDT 2008 i686 GNU/Linux ( With same OS openser created core dump)

Is there any anything I might be missing? please help me to generate core dump , it will be very helpful for debugging.

Crash:
=====
Crash observed when notify sent out for RLS list in case of PUBLISH received. for more information please find the attached logs.

Dec 15 05:12:44 [15278] DBG:core:parse_uri:  uri params:
   transport=<>, val=<>, proto=0
Dec 15 05:12:44 [15278] DBG:core:parse_uri:    user-param=<>, val=<>
Dec 15 05:12:44 [15278] DBG:core:parse_uri:    method=<>, val=<>
Dec 15 05:12:44 [15278] DBG:core:parse_uri:    ttl=<>, val=<>
Dec 15 05:12:44 [15278] DBG:core:parse_uri:    maddr=<>, val=<>
Dec 15 05:12:44 [15278] DBG:core:parse_uri:    lr=<lr>
Dec 15 05:12:44 [15278] DBG:core:mk_proxy: doing DNS lookup...
Dec 15 05:12:44 [15278] DBG:tm:dlg2hash: 21643
Dec 15 05:12:44 [15278] DBG:tm:print_request_uri: sip:c3-1 at 192.168.126.151:40000
Dec 15 05:12:44 [15278] DBG:tm:set_timer: relative timeout is 500000
Dec 15 05:12:44 [15278] DBG:tm:insert_timer_unsafe: [4]: 0xb5be4a64 (20500000)
Dec 15 05:12:44 [15278] DBG:tm:set_timer: relative timeout is 30
Dec 15 05:12:44 [15278] DBG:tm:insert_timer_unsafe: [0]: 0xb5be4a84 (50)
Dec 15 05:12:44 [15278] DBG:rls:timer_send_notify: Found rl-subs record in hash table
Dec 15 05:12:44 [15277] INFO:core:handle_sigs: child process 15278 exited by a signal 11
Dec 15 05:12:44 [15277] INFO:core:handle_sigs: core was not generated
Dec 15 05:12:44 [15277] INFO:core:handle_sigs: terminating due to SIGCHLD
Dec 15 05:12:44 [15279] INFO:core:sig_usr: signal 15 received

Dec 15 05:12:44 [15277] DBG:core:shm_mem_destroy:
Dec 15 05:12:44 [15277] DBG:core:shm_mem_destroy: destroying the shared memory lock
Dec 15 05:12:44 [15277] DBG:core:handle_sigs: terminating due to SIGCHLD

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

Comment By: Nathan (rmnathan)
Date: 2009-02-02 14:34

Message:
Hi Anca,
I have tested with new clone . The crash is not observed. but i have seen
lot of error message like beow. I will update log and call flow for this
error message in the respective bug item.

Feb  2 14:26:28 [26461] ERROR:rls:parse_subs_state: terminated state and
no reason foundFeb  2 14:26:28 [26461] ERROR:rls:rls_handle_notify: while
parsing 'Subscription-State' header
Feb  2 14:26:28 [26461] ERROR:rls:parse_subs_state: terminated state and
no reason foundFeb  2 14:26:28 [26461] ERROR:rls:rls_handle_notify: while
parsing 'Subscription-State' header
Feb  2 14:26:29 [26461] ERROR:rls:rls_notify_callback: record not found in
hash table
Feb  2 14:26:34 [26461] ERROR:rls:parse_subs_state: terminated state and
no reason foundFeb  2 14:26:34 [26461] ERROR:rls:rls_handle_notify: while
parsing 'Subscription-State' header
Feb  2 14:26:34 [26461] ERROR:rls:parse_subs_state: terminated state and
no reason foundFeb  2 14:26:34 [26461] ERROR:rls:rls_handle_notify: while
parsing 'Subscription-State' header

Thanks lot

Regards,
rmnathan

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

Comment By: Anca Vamanu (anca_vamanu)
Date: 2009-01-23 18:46

Message:
Hi Rmnathan,

Yesterday I have found a double free bug in rls module. Can you please
update your version and test again?

Thanks and regards,
Anca

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

Comment By: Nathan (rmnathan)
Date: 2009-01-22 12:23

Message:
Hi Anca,
Any update on this issue?

Regards,
rmnathan

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

Comment By: Nobody/Anonymous (nobody)
Date: 2009-01-12 19:25

Message:
Hi Anca,
The details of error message and call scenario as follows

1.Error Message
=================
 Only following error message is getting at the time of crashing
Jan 12 08:20:10 [27860] WARNING:core:main: no fork mode
Jan 12 08:21:10 [27860] ERROR:core:db_do_insert: invalid parameter value
Jan 12 08:21:10 [27860] ERROR:pua:db_update: while inserting in db table
pua

2. Setup details
=================
UE 1 
	-------	   PROXY  --------- Opensips
UE 2 

Note : All users are in same domain

UE 2 will have following list in openxcap table
----------------------------------------------------
It has 100 list  for each user

 uE2_1, UE2_2, UE2_3 ..
UE2_1 list will have 5 entry uri like UE1_1,UE1_2,UE1_3,UE1_4,UE1_5
UE2_2 list will have 5 entry uri like UE1_2,UE1_3,UE1_4,UE1_5,UE1_6
simillary it will go for 100 user
.
.
UE2_100 list will have 5 entry uri like UE1_100,UE1_1,UE1_2,UE1_3,UE1_4

UE 1 will have following list in openxcap table
----------------------------------------------------
It has 100 list  for each user

 uE2_1, UE2_2, UE2_3 ..
UE1_1 list will have 5 entry uri like UE2_1,UE2_2,UE2_3,UE2_4,UE2_5
UE1_2 list will have 5 entry uri like UE2_2,UE2_3,UE2_4,UE2_5,UE2_6
simillary it will go for 100 user
.
.

UE1_100 list will have 5 entry uri like UE2_100,UE2_1,UE2_2,UE2_3,UE2_4


Sample Message flow for UE1 for one user 
========================================

1. UE 1(UE1_1) will send subscribe message to rls list UE1_1 
2. UE 1 will send publish 

simillary UE2_1 .. will send subscribe and publish.


Regards,
rmnathan

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

Comment By: Anca Vamanu (anca_vamanu)
Date: 2009-01-08 21:36

Message:
Hi,

I did not succeeded to get segmentation fault on my machine or to detect
the problem in the code and from your trace. Can you please tell me if see
any errors in you log file? And what scenario are you using when testing?

regards,
Anca



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

Comment By: Nathan (rmnathan)
Date: 2009-01-07 18:22

Message:
crash 2 with full bt trace
===================
error message before crashing:
Jan  7 07:21:05 [10134] ERROR:core:db_do_insert: invalid parameter value
Jan  7 07:21:05 [10134] ERROR:pua:db_update: while inserting in db table
pua

Core was generated by `/usr/local/sbin/opensips -m 1024'.
Program terminated with signal 11, Segmentation fault.
#0  fm_malloc (qm=0x81a3ba0, size=1528) at mem/f_malloc.c:267
267                             if ((*f)->size>=size) goto found;
(gdb) bt full
#0  fm_malloc (qm=0x81a3ba0, size=1528) at mem/f_malloc.c:267
        f = (struct fm_frag **) 0x81a4330
        hash = 239
#1  0xb78f1b51 in agg_body_sendn_update (rl_uri=0x81b31b0,
boundary_string={s = 0x81b1970 "gQIIPDYu2UDVZoZv5NTp3DgT", len = 24},
rlmi_body=0xbf9ad484,
    multipart_body=0xbf9ad47c, subs=0x81b31b0, hash_code=1381) at
notify.c:238
        cid = {s = 0x81b1c50 "1231330858.sip:c5-1 at 10.6.2.246.1189641421",
len = 41}
        len = 1526
        body = {s = 0x0, len = 0}
        __FUNCTION__ = "agg_body_sendn_update"
#2  0xb78f4efe in timer_send_notify (ticks=180, param=0x0) at
resource_notify.c:544
        query_cols = {0xb7906844, 0xb7ab9510}
        update_cols = {0xb7906844}
        result_cols = {0xb7906834, 0xb790683c, 0xb790684c, 0xb790685c,
0xb7906854, 0xb7906864, 0x0}
        query_vals = {{type = DB_INT, nul = 0, free = 2007220120, val =
{int_val = 1, double_val = 1.6975966328216244e-313, time_val = 1,
      string_val = 0x1 <Address 0x1 out of bounds>, str_val = {s = 0x1
<Address 0x1 out of bounds>, len = 8}, blob_val = {
        s = 0x1 <Address 0x1 out of bounds>, len = 8}, bitmap_val = 1}},
{type = 135996560, nul = 0, free = -1080372044, val = {int_val = 135974160,
      double_val = 6.7180161178120992e-316, time_val = 135974160,
string_val = 0x81acd10 "?\225??", str_val = {s = 0x81acd10 "?\225??",
len = 0},
      blob_val = {s = 0x81acd10 "?\225??", len = 0}, bitmap_val =
135974160}}}
        update_vals = {{type = DB_DATETIME, nul = 2007220120, free =
-1213492080, val = {int_val = -1, double_val = -1.5830897899132156e-40,
time_val = -1,
      string_val = 0xffffffff <Address 0xffffffff out of bounds>, str_val
= {s = 0xffffffff <Address 0xffffffff out of bounds>, len = -1213492016},
      blob_val = {s = 0xffffffff <Address 0xffffffff out of bounds>, len =
-1213492016}, bitmap_val = 4294967295}}}
        i = 5
        result = (db_res_t *) 0x81b1768
        prev_did = 0x481c5c3c
"c5-1-80;227413568;97b57f2144c425bc44f2e7a21eb22549-57d9"
        curr_did = 0x481c601c
"c6-1-80;227413312;97b57f2144c425bc44f2e7a21eb22549-4c39"
        row_vals = (db_val_t *) 0x81b2d78
        resource_uri = 0x481c6054 "sip:s6-1 at 10.6.2.246"
        pres_state = 0x481c6080 "<?xml version=\"1.0\"
encoding=\"UTF-8\"?>\n<presence xmlns=\"urn:ietf:params:xml:ns:pidf\"
xmlns:rpid=\"urn:ietf:params:xml:ns:pidf:rpid\"
xmlns:dm=\"urn:ietf:params:xml:ns:pidf:data-model\"
xmlns:pcp=\"urn:ietf"...
        callid = {s = 0x481c5c3c
"c5-1-80;227413568;97b57f2144c425bc44f2e7a21eb22549-57d9", len = 7}
        to_tag = {s = 0x481c5c4e "97b57f2144c425bc44f2e7a21eb22549-57d9",
len = 37}
        from_tag = {s = 0x481c5c44
"227413568;97b57f2144c425bc44f2e7a21eb22549-57d9", len = 9}
        rlmi_doc = (xmlDocPtr) 0x481af758
        list_node = (xmlNodePtr) 0x481accb8
        instance_node = (xmlNodePtr) 0x481af9a0
        resource_node = (xmlNodePtr) 0x481af8b0
        hash_code = 1381
        size = 2048
        buf_len = 1004
        buf = 0x81b3380
"--gQIIPDYu2UDVZoZv5NTp3DgT\r\n\r\nContent-Transfer-Encoding:
binary\r\nContent-ID:
<1231330858.sip:s5-1 at 10.6.2.246.596516649>\r\nContent-Type:
application/pidf+xml\r\n\r\n<?xml version=\"1.0\"
encoding=\"UTF-8\"?>\n<p"...
        auth_state = <value optimized out>
        contor = 1
        auth_state_flag = 2
        bstr = {s = 0x81b1970 "gQIIPDYu2UDVZoZv5NTp3DgT", len = 24}
        rlmi_cont = {
  s = 0x481aed98 "<?xml version=\"1.0\"?>\n<list
uri=\"sip:c5-1 at 10.6.2.246\" xmlns=\"urn:ietf:params:xml:ns:rlmi\"
version=\"5\" fullState=\"false\">\n  <resource
uri=\"sip:s5-1 at 10.6.2.246\">\n    <instance id=\"icDW4oK5\"
state=\"activ"..., len = 274}
        multi_cont = {
  s = 0x81b3380
"--gQIIPDYu2UDVZoZv5NTp3DgT\r\n\r\nContent-Transfer-Encoding:
binary\r\nContent-ID:
<1231330858.sip:s5-1 at 10.6.2.246.596516649>\r\nContent-Type:
application/pidf+xml\r\n\r\n<?xml version=\"1.0\"
encoding=\"UTF-8\"?>\n<p"..., len = 1004}
        s = (subs_t *) 0x77af7598
        dialog = (subs_t *) 0x81b31b0
        rl_uri = 0x81b2a80 "sip:c5-1 at 10.6.2.246"
        str_aux = <value optimized out>
        __FUNCTION__ = "timer_send_notify"
#3  0x080ccfb5 in start_timer_processes () at timer.c:280
---Type <return> to continue, or q <return> to quit---
        tpl = (struct sr_timer_process *) 0x81acad8
        pid = <value optimized out>
        first = <value optimized out>
        __FUNCTION__ = "start_timer_processes"
#4  0x0806f189 in main (argc=3, argv=0xbf9ad664) at main.c:666
        cfg_log_stderr = 0
        cfg_stream = (FILE *) 0x481a4008
        c = <value optimized out>
        r = <value optimized out>
        tmp = 0xbf9aedec ""
        tmp_len = <value optimized out>
        port = <value optimized out>
        proto = <value optimized out>
        ret = <value optimized out>
        seed = 4221279407
        rfd = 4
        __FUNCTION__ = "main"
(gdb)

crash 3 with full bt trace
===================
error message before crashing:
Jan  7 07:29:00 [10190] ERROR:db_mysql:db_mysql_str2val: invalid parameter
value
Jan  7 07:29:00 [10190] ERROR:db_mysql:db_mysql_convert_row: failed to
convert value
Jan  7 07:29:09 [10189] ERROR:core:db_do_insert: invalid parameter value
Jan  7 07:29:09 [10189] ERROR:pua:db_update: while inserting in db table
pua

Core was generated by `/usr/local/sbin/opensips -m 1024'.
Program terminated with signal 11, Segmentation fault.
#0  db_free_row (_r=0x81b79e8) at db/db_row.c:62
62                      switch (VAL_TYPE(_val)) {
(gdb) bt full
#0  db_free_row (_r=0x81b79e8) at db/db_row.c:62
        col = 0
        _val = (db_val_t *) 0x0
        __FUNCTION__ = "db_free_row"
#1  0xb7d9b580 in db_mysql_convert_row (_h=0x81b3820, _res=0x81ad938,
_r=0x81b79e8) at row.c:69
        lengths = (long unsigned int *) 0x481aebcc
        i = 135935876
        __FUNCTION__ = "db_mysql_convert_row"
#2  0xb7d9aeca in db_mysql_convert_result (_h=0x81b3820, _r=0x81ad938) at
res.c:171
        __FUNCTION__ = "db_mysql_convert_result"
#3  0xb7d98a2f in db_mysql_store_result (_h=0x81b3820, _r=0xbf9f4500) at
dbase.c:177
        __FUNCTION__ = "db_mysql_store_result"
#4  0x0811b94f in db_do_query (_h=0x81b3820, _k=0xbf9f44f4, _op=0x0,
_v=0xbf9f4474, _c=0xbf9f449c, _n=1, _nc=6, _o=0xb78e6834, _r=0xbf9f4500,
    val2str=0xb7d9b780 <db_mysql_val2str>, submit_query=0xb7d98de9
<db_mysql_submit_query>, store_result=0xb7d989c7 <db_mysql_store_result>)
    at db/db_query.c:105
        tmp = <value optimized out>
        off = 132
        ret = <value optimized out>
        __FUNCTION__ = "db_do_query"
#5  0xb7d97d05 in db_mysql_query (_h=0x81b3820, _k=0xbf9f44f4, _op=0x0,
_v=0xbf9f4474, _c=0xbf9f449c, _n=1, _nc=6, _o=0xb78e6834, _r=0xbf9f4500)
    at dbase.c:247
No locals.
#6  0xb78d4c75 in timer_send_notify (ticks=80, param=0x0) at
resource_notify.c:493
        query_cols = {0xb78e6844, 0x0}
        update_cols = {0xb78e6844}
        result_cols = {0xb78e6834, 0xb78e683c, 0xb78e684c, 0xb78e685c,
0xb78e6854, 0xb78e6864, 0x0}
        query_vals = {{type = DB_INT, nul = 0, free = 2007089048, val =
{int_val = 1, double_val = -2.766852607421637e-39, time_val = 1,
      string_val = 0x1 <Address 0x1 out of bounds>, str_val = {s = 0x1
<Address 0x1 out of bounds>, len = -1209130788}, blob_val = {
        s = 0x1 <Address 0x1 out of bounds>, len = -1209130788},
bitmap_val = 1}}, {type = 3085836512, nul = -1209131020, free = 310, val =
{int_val = 310,
      double_val = -0.03053575754165757, time_val = 310, string_val =
0x136 <Address 0x136 out of bounds>, str_val = {
        s = 0x136 <Address 0x136 out of bounds>, len = -1080081212},
blob_val = {s = 0x136 <Address 0x136 out of bounds>, len = -1080081212},
      bitmap_val = 310}}}
        update_vals = {{type = DB_DATETIME, nul = 2007089048, free =
-1080081152, val = {int_val = -1, double_val = -3.3348689399357007e-39,
time_val = -1,
      string_val = 0xffffffff <Address 0xffffffff out of bounds>, str_val
= {s = 0xffffffff <Address 0xffffffff out of bounds>, len = -1208866784},
      blob_val = {s = 0xffffffff <Address 0xffffffff out of bounds>, len =
-1208866784}, bitmap_val = 4294967295}}}
        i = <value optimized out>
        result = (db_res_t *) 0x81ad938
        prev_did = <value optimized out>
        curr_did = <value optimized out>
        row_vals = <value optimized out>
        resource_uri = <value optimized out>
        pres_state = <value optimized out>
        callid = {s = 0x0, len = 0}
        to_tag = {s = 0x481c67ed
"h\034H_h\034H`h\034H?k\034Hc3-2-80;210632768;97b57f2144c425bc44f2e7a21eb22549-f3e9",
len = 79}
        from_tag = {s = 0x481c67e4
"4h\034HHh\034HJh\034H_h\034H`h\034H?k\034Hc3-2-80;210632768;97b57f2144c425bc44f2e7a21eb22549-f3e9",
len = 8}
        rlmi_doc = <value optimized out>
        list_node = <value optimized out>
        instance_node = <value optimized out>
        resource_node = <value optimized out>
        hash_code = <value optimized out>
        size = <value optimized out>
        buf_len = <value optimized out>
        buf = <value optimized out>
        auth_state = <value optimized out>
        contor = <value optimized out>
        auth_state_flag = <value optimized out>
        bstr = {s = 0x0, len = 0}
---Type <return> to continue, or q <return> to quit---
        rlmi_cont = {s = 0x0, len = 0}
        multi_cont = {s = 0x0, len = 8}
        s = <value optimized out>
        dialog = <value optimized out>
        rl_uri = <value optimized out>
        str_aux = <value optimized out>
        __FUNCTION__ = "timer_send_notify"
#7  0x080ccfb5 in start_timer_processes () at timer.c:280
        tpl = (struct sr_timer_process *) 0x81acad8
        pid = <value optimized out>
        first = <value optimized out>
        __FUNCTION__ = "start_timer_processes"
#8  0x0806f189 in main (argc=3, argv=0xbf9f46b4) at main.c:666
        cfg_log_stderr = 0
        cfg_stream = (FILE *) 0x481a4008
        c = <value optimized out>
        r = <value optimized out>
        tmp = 0xbf9f5dec ""
        tmp_len = <value optimized out>
        port = <value optimized out>
        proto = <value optimized out>
        ret = <value optimized out>
        seed = 3089561270
        rfd = 4
        __FUNCTION__ = "main"
(gdb)



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

Comment By: Nathan (rmnathan)
Date: 2009-01-07 17:45

Message:
Hi
the full trace as follows 
 
Core was generated by `/usr/local/sbin/opensips'.
Program terminated with signal 11, Segmentation fault.
#0  0xb78e7eca in timer_send_notify (ticks=120, param=0x0) at
resource_notify.c:721
721                            
if(strncmp(row_vals[resource_uri_col].val.string_val,
(gdb) bt full
#0  0xb78e7eca in timer_send_notify (ticks=120, param=0x0) at
resource_notify.c:721
        query_cols = {0xb78f8844, 0xb7aab510}
        update_cols = {0x0}
        result_cols = {0xb78f8834, 0xb78f883c, 0xb78f884c, 0xb78f885c,
0xb78f8854, 0xb78f8864, 0x0}
        query_vals = {{type = DB_INT, nul = 0, free = -1247617128, val =
{int_val = 1, double_val = 4.2439915824246103e-314, time_val = 1,
      string_val = 0x1 <Address 0x1 out of bounds>, str_val = {s = 0x1
<Address 0x1 out of bounds>, len = 2}, blob_val = {
        s = 0x1 <Address 0x1 out of bounds>, len = 2}, bitmap_val = 1}},
{type = DB_DOUBLE, nul = 0, free = -1081894044, val = {int_val = 135974160,
      double_val = 6.7180161178120992e-316, time_val = 135974160,
string_val = 0x81acd10 "??????\032\b", str_val = {s = 0x81acd10
"??????\032\b", len = 0},
      blob_val = {s = 0x81acd10 "??????\032\b", len = 0}, bitmap_val
= 135974160}}}
        update_vals = {{type = DB_DATETIME, nul = -1247617128, free =
-1243838944, val = {int_val = -1213549416, double_val =
-1.5328670054899573e-40,
      time_val = -1213549416, string_val = 0xb7aab498 "?S??\006",
str_val = {s = 0xb7aab498 "?S??\006", len = -1213549360}, blob_val = {
        s = 0xb7aab498 "?S??\006", len = -1213549360}, bitmap_val =
3081417880}}}
        i = 298
        result = (db_res_t *) 0x828f678
        prev_did = 0x4821159c
"s6-13-80;100595200;97b57f2144c425bc44f2e7a21eb22549-1265"
        curr_did = 0x48211d5c
"s6-14-80;218035712;97b57f2144c425bc44f2e7a21eb22549-365a"
        row_vals = (db_val_t *) 0x64697072
        resource_uri = <value optimized out>
        pres_state = 0x48211dc2 "<?xml version=\"1.0\"
encoding=\"UTF-8\"?>\n<presence xmlns=\"urn:ietf:params:xml:ns:pidf\"
xmlns:rpid=\"urn:ietf:params:xml:ns:pidf:rpid\"
xmlns:dm=\"urn:ietf:params:xml:ns:pidf:data-model\"
xmlns:pcp=\"urn:ietf"...
        callid = {s = 0x48211d5c
"s6-14-80;218035712;97b57f2144c425bc44f2e7a21eb22549-365a", len = 8}
        to_tag = {s = 0x48211d6f "97b57f2144c425bc44f2e7a21eb22549-365a",
len = 37}
        from_tag = {s = 0x48211d65
"218035712;97b57f2144c425bc44f2e7a21eb22549-365a", len = 9}
        rlmi_doc = (xmlDocPtr) 0x481aec20
        list_node = (xmlNodePtr) 0x481accb8
        instance_node = (xmlNodePtr) 0x481f0da0
        resource_node = (xmlNodePtr) 0x481af8c0
        hash_code = 349
        size = 6144
        buf_len = 1007
        buf = 0x8298040
"--uiJUnfDUyfcSFWRINqnYyVEx\r\n\r\nContent-Transfer-Encoding:
binary\r\nContent-ID:
<1231322726.sip:c6-18 at 10.6.2.246.596516649>\r\nContent-Type:
application/pidf+xml\r\n\r\n<?xml version=\"1.0\"
encoding=\"UTF-8\"?>\n<"...
        auth_state = <value optimized out>
        contor = 1
        auth_state_flag = <value optimized out>
        bstr = {s = 0x8292c30 "uiJUnfDUyfcSFWRINqnYyVEx", len = 24}
        rlmi_cont = {
  s = 0x481f0fd8 "pT??pT???\017\037H?\017\037H.0\"?>\n<list
uri=\"sip:s6-13 at 10.6.2.246\" xmlns=\"urn:ietf:params:xml:ns:rlmi\"
version=\"2\" fullState=\"false\">\n  <resource
uri=\"sip:c6-17 at 10.6.2.246\">\n    <instance id=\"icDW4oK5\"
state=\"act"..., len = 959}
        multi_cont = {
  s = 0x8298040
"--uiJUnfDUyfcSFWRINqnYyVEx\r\n\r\nContent-Transfer-Encoding:
binary\r\nContent-ID:
<1231322726.sip:c6-18 at 10.6.2.246.596516649>\r\nContent-Type:
application/pidf+xml\r\n\r\n<?xml version=\"1.0\"
encoding=\"UTF-8\"?>\n<"..., len = 6053}
        s = (subs_t *) 0xb602c300
        dialog = (subs_t *) 0x81a7ef0
        rl_uri = 0x8291670 "sip:s6-14 at 10.6.2.246"
        str_aux = <value optimized out>
        __FUNCTION__ = "timer_send_notify"
#1  0x080ccfb5 in start_timer_processes () at timer.c:280
        tpl = (struct sr_timer_process *) 0x81acad8
        pid = <value optimized out>
        first = <value optimized out>
        __FUNCTION__ = "start_timer_processes"
#2  0x0806f189 in main (argc=1, argv=0xbf839d14) at main.c:666
        cfg_log_stderr = 0
        cfg_stream = (FILE *) 0x481a4008
        c = <value optimized out>
        r = <value optimized out>
---Type <return> to continue, or q <return> to quit---
        tmp = 0x8166200 "\034a\026\bhF??@???"
        tmp_len = <value optimized out>
        port = <value optimized out>
        proto = <value optimized out>
        ret = <value optimized out>
        seed = 82752229
        rfd = 4
        __FUNCTION__ = "main"
(gdb)

Regards,
rmnathan

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

Comment By: Nobody/Anonymous (nobody)
Date: 2009-01-07 16:34

Message:
It would help to provide the backtrace with the full context and the value
of the local variables. To do that use "bt full" instead of just "bt".

Dan


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

Comment By: Nathan (rmnathan)
Date: 2009-01-07 16:10

Message:
Hi Anca,
I observed few crashes as follows while testing with new trunck build.

Crash 1:
======
Core was generated by `/usr/local/sbin/opensips -m 1024'.
Program terminated with signal 11, Segmentation fault.
#0  0xb7e18d00 in strncmp () from /lib/libc.so.6
(gdb) bt
#0  0xb7e18d00 in strncmp () from /lib/libc.so.6
#1  0xb78cfee3 in timer_send_notify (ticks=40, param=0x0) at
resource_notify.c:721
#2  0x080ccfb5 in start_timer_processes () at timer.c:280
#3  0x0806f189 in main (argc=3, argv=0xbfb57014) at main.c:666

Crash 2:
======
Program terminated with signal 11, Segmentation fault.
#0  fm_malloc (qm=0x81a3ba0, size=2640) at mem/f_malloc.c:267
267                             if ((*f)->size>=size) goto found;
(gdb) bt
#0  fm_malloc (qm=0x81a3ba0, size=2640) at mem/f_malloc.c:267
#1  0xb78dcb51 in agg_body_sendn_update (rl_uri=0x81a7ef0,
boundary_string={s = 0x81dadc0 "j5dDEBAL5H1LAtor2qUGI2ac", len = 24},
rlmi_body=0xbfef61d4,
    multipart_body=0xbfef61cc, subs=0x81a7ef0, hash_code=1978) at
notify.c:238
#2  0xb78dfefe in timer_send_notify (ticks=60, param=0x0) at
resource_notify.c:544
#3  0x080ccfb5 in start_timer_processes () at timer.c:280
#4  0x0806f189 in main (argc=3, argv=0xbfef63b4) at main.c:666

crash 3:
======
#0  0xb78e7eca in timer_send_notify (ticks=120, param=0x0) at
resource_notify.c:721
721                            
if(strncmp(row_vals[resource_uri_col].val.string_val,
(gdb) bt
#0  0xb78e7eca in timer_send_notify (ticks=120, param=0x0) at
resource_notify.c:721
#1  0x080ccfb5 in start_timer_processes () at timer.c:280
#2  0x0806f189 in main (argc=1, argv=0xbf839d14) at main.c:666

crash 4:
======
Core was generated by `/usr/local/sbin/opensips -m 1024'.
Program terminated with signal 11, Segmentation fault.
#0  db_free_row (_r=0x81c25d0) at db/db_row.c:62
62                      switch (VAL_TYPE(_val)) {

crash 5:
======
Core was generated by `/usr/local/sbin/opensips'.
Program terminated with signal 11, Segmentation fault.
#0  0x080f9282 in parse_uri (buf=0x8 <Address 0x8 out of bounds>,
len=135995841, uri=0xbf9fbfe0) at parser/parse_uri.c:329
329             scheme=buf[0]+(buf[1]<<8)+(buf[2]<<16)+(buf[3]<<24);


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

Comment By: Anca Vamanu (anca_vamanu)
Date: 2009-01-06 20:11

Message:
Hi Meganathan,

I think that I have finally found the bug this time. Can you please
update, test again and confirm?

Thanks and regards,
Anca

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

Comment By: Nathan (rmnathan)
Date: 2008-12-31 15:07

Message:
Hi Anca,
 Any update on this issue?

Regards,
Meganathan.

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

Comment By: Nathan (rmnathan)
Date: 2008-12-18 20:15

Message:
Hi Anca 
 I have retested with latest build (rev 5071). Again I got the crash  

(gdb) bt
#0  0xb7e1861d in _IO_str_overflow () from /lib/libc.so.6
#1  0xb7e17747 in _IO_default_xsputn () from /lib/libc.so.6
#2  0xb7deea94 in vfprintf () from /lib/libc.so.6
#3  0xb7e0c92c in vsprintf () from /lib/libc.so.6
#4  0xb7df775e in sprintf () from /lib/libc.so.6
#5  0xb78d810b in timer_send_notify (ticks=40, param=0x0) at
resource_notify.c:700
#6  0x080ccb55 in start_timer_processes () at timer.c:280
#7  0x0806ef69 in main (argc=1, argv=0xbfa78f44) at main.c:666

Regards,
rmnathan


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

Comment By: Anca Vamanu (anca_vamanu)
Date: 2008-12-18 17:58

Message:
Hi rmnathan,

I have made some changes in the rls module. 
Can you please update and test again?

regards,
Anca

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

Comment By: Nathan (rmnathan)
Date: 2008-12-16 15:42

Message:
Hi Anca,
After i compiled with following commands i got core dump with line
numbers.

make
echo $?
make prefix=/usr/local/ install

Program terminated with signal 11, Segmentation fault.
#0  0xb7e5161d in _IO_str_overflow () from /lib/libc.so.6
(gdb) bt
#0  0xb7e5161d in _IO_str_overflow () from /lib/libc.so.6
#1  0xb7e50747 in _IO_default_xsputn () from /lib/libc.so.6
#2  0xb7e27a94 in vfprintf () from /lib/libc.so.6
#3  0xb7e4592c in vsprintf () from /lib/libc.so.6
#4  0xb7e3075e in sprintf () from /lib/libc.so.6
#5  0xb7911d53 in timer_send_notify (ticks=40, param=0x0) at
resource_notify.c:687
#6  0x080ccb55 in start_timer_processes () at timer.c:280
#7  0x0806ef69 in main (argc=1, argv=0xbf805cf4) at main.c:666

regards,
rmnathan


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

Comment By: Nathan (rmnathan)
Date: 2008-12-16 15:15

Message:
Hi Anca,
I have tried with latest trunk build (rev 5060), am getting the same
crash.
I have set 'ulimit -c unlimited' also but the line numbers not getting
printed.

Core was generated by `opensips'.
Program terminated with signal 11, Segmentation fault.
#0  0xb7ec161d in _IO_str_overflow () from /lib/libc.so.6
(gdb) bt
#0  0xb7ec161d in _IO_str_overflow () from /lib/libc.so.6
#1  0xb7ec0747 in _IO_default_xsputn () from /lib/libc.so.6
#2  0xb7e97a94 in vfprintf () from /lib/libc.so.6
#3  0xb7eb592c in vsprintf () from /lib/libc.so.6
#4  0xb7ea075e in sprintf () from /lib/libc.so.6
#5  0xb799a25d in timer_send_notify () from
/usr/local//lib/opensips/modules/rls.so
#6  0x080b1194 in timer_ticker ()
#7  0x080b0fc5 in run_timer_process ()
#8  0x080b12ff in start_timer_processes ()
#9  0x08065cdd in main_loop ()
#10 0x08067f53 in main ()

Regards
rmnathan

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

Comment By: Anca Vamanu (anca_vamanu)
Date: 2008-12-15 19:49

Message:
Hi rmnathan,

I have tested myself and got a crash after some time - it was due to a
recent change that I made. I have commited the fix in trunk.
However I am not really sure it is the same as you have seen, as in your
trace there isn't enough information -like line numbers. Can you please
update and test again and report if you see the crash again. 
Btw, have you run: 'ulimit -c unlimited'?

regards,
Anca 


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

Comment By: Nathan (rmnathan)
Date: 2008-12-15 16:47

Message:
Finally core has created. Please see below

stinbng46:/# gdb /usr/local/sbin/opensips core
GNU gdb 6.4.90-debian
Copyright (C) 2006 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you
are
welcome to change it and/or distribute copies of it under certain
conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for
details.
This GDB was configured as "i486-linux-gnu"...Using host libthread_db
library "/lib/libthread_db.so.1".


warning: Can't read pathname for load map: Input/output error.
Reading symbols from /lib/libdl.so.2...done.
Loaded symbols for /lib/libdl.so.2
Reading symbols from /lib/libresolv.so.2...done.
Loaded symbols for /lib/libresolv.so.2
Reading symbols from /lib/libc.so.6...done.
Loaded symbols for /lib/libc.so.6
Reading symbols from /lib/ld-linux.so.2...done.
Loaded symbols for /lib/ld-linux.so.2
Reading symbols from /usr/local/lib/opensips/modules/db_mysql.so...done.
Loaded symbols for /usr/local//lib/opensips/modules/db_mysql.so
Reading symbols from /usr/lib/libmysqlclient.so.15...done.
Loaded symbols for /usr/lib/libmysqlclient.so.15
Reading symbols from /lib/libpthread.so.0...done.
Loaded symbols for /lib/libpthread.so.0
Reading symbols from /lib/libcrypt.so.1...done.
Loaded symbols for /lib/libcrypt.so.1
Reading symbols from /lib/libnsl.so.1...done.
Loaded symbols for /lib/libnsl.so.1
Reading symbols from /lib/libm.so.6...done.
Loaded symbols for /lib/libm.so.6
Reading symbols from /usr/lib/libz.so.1...done.
Loaded symbols for /usr/lib/libz.so.1
Reading symbols from /usr/local/lib/opensips/modules/sl.so...done.
Loaded symbols for /usr/local//lib/opensips/modules/sl.so
Reading symbols from /usr/local/lib/opensips/modules/maxfwd.so...done.
Loaded symbols for /usr/local//lib/opensips/modules/maxfwd.so
Reading symbols from /usr/local/lib/opensips/modules/textops.so...done.
Loaded symbols for /usr/local//lib/opensips/modules/textops.so
Reading symbols from /usr/local/lib/opensips/modules/tm.so...done.
Loaded symbols for /usr/local//lib/opensips/modules/tm.so
Reading symbols from /usr/local/lib/opensips/modules/rr.so...done.
Loaded symbols for /usr/local//lib/opensips/modules/rr.so
Reading symbols from /usr/local/lib/opensips/modules/presence.so...done.
Loaded symbols for /usr/local//lib/opensips/modules/presence.so
Reading symbols from /usr/lib/libxml2.so.2...done.
Loaded symbols for /usr/lib/libxml2.so.2
Reading symbols from /usr/local/lib/opensips/modules/avpops.so...done.
Loaded symbols for /usr/local//lib/opensips/modules/avpops.so
Reading symbols from /usr/local/lib/opensips/modules/pua.so...done.
Loaded symbols for /usr/local//lib/opensips/modules/pua.so
Reading symbols from /usr/local/lib/opensips/modules/mi_fifo.so...done.
Loaded symbols for /usr/local//lib/opensips/modules/mi_fifo.so
Reading symbols from
/usr/local/lib/opensips/modules/presence_xml.so...done.
Loaded symbols for /usr/local//lib/opensips/modules/presence_xml.so
Reading symbols from /usr/local/lib/opensips/modules/rls.so...done.
Loaded symbols for /usr/local//lib/opensips/modules/rls.so
Reading symbols from /usr/local/lib/opensips/modules/xlog.so...done.
Loaded symbols for /usr/local//lib/opensips/modules/xlog.so
Reading symbols from /usr/local/lib/opensips/modules/signaling.so...done.
Loaded symbols for /usr/local//lib/opensips/modules/signaling.so
Reading symbols from /lib/libnss_db.so.2...done.
Loaded symbols for /lib/libnss_db.so.2
Reading symbols from /lib/libnss_files.so.2...done.
Loaded symbols for /lib/libnss_files.so.2
Reading symbols from /usr/lib/libdb3.so.3...done.
Loaded symbols for /usr/lib/libdb3.so.3
Core was generated by `/usr/local/sbin/opensips -D'.
Program terminated with signal 11, Segmentation fault.
#0  0xb7e9f61d in _IO_str_overflow () from /lib/libc.so.6
(gdb) bt
#0  0xb7e9f61d in _IO_str_overflow () from /lib/libc.so.6
#1  0xb7e9e747 in _IO_default_xsputn () from /lib/libc.so.6
#2  0xb7e75a94 in vfprintf () from /lib/libc.so.6
#3  0xb7e9392c in vsprintf () from /lib/libc.so.6
#4  0xb7e7e75e in sprintf () from /lib/libc.so.6
#5  0xb7978256 in timer_send_notify () from
/usr/local//lib/opensips/modules/rls.so
#6  0x080b11a0 in timer_ticker ()
#7  0x080b0fd1 in run_timer_process ()
#8  0x080b130b in start_timer_processes ()
#9  0x08065cdd in main_loop ()
#10 0x08067f5f in main ()

Regards
rmnathan


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

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


From noreply at sourceforge.net  Mon Feb  2 10:14:19 2009
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 02 Feb 2009 09:14:19 +0000
Subject: [OpenSIPS-Devel] [ opensips-Bugs-2523454 ] Error in handling rls
	NOTIFY
Message-ID: <E1LTusl-0005sJ-53@665xhf1.ch3.sourceforge.com>

Bugs item #2523454, was opened at 2009-01-20 17:25
Message generated for change (Comment added) made by rmnathan
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=2523454&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: Nathan (rmnathan)
Assigned to: Anca Vamanu (anca_vamanu)
Summary: Error in handling rls NOTIFY

Initial Comment:
Hi
The following error message are printed while handling rls notify.
Jan 20 06:45:44 [7833] ERROR:rls:parse_subs_state: terminated state and no reason foundJan 20 06:45:44 [7833] ERROR:rls:rls_handle_notify: while parsing 'Subscription-State' header
Jan 20 06:45:44 [7833] ERROR:rls:parse_subs_state: terminated state and no reason foundJan 20 06:45:44 [7833] ERROR:rls:rls_handle_notify: while parsing 'Subscription-State' header
Jan 20 06:45:44 [7833] ERROR:rls:parse_subs_state: terminated state and no reason foundJan 20 06:45:44 [7833] ERROR:rls:rls_handle_notify: while parsing 'Subscription-State' header
Jan 20 06:45:52 [7833] ERROR:rls:parse_subs_state: terminated state and no reason foundJan 20 06:45:52 [7833] ERROR:rls:rls_handle_notify: while parsing 'Subscription-State' header
Jan 20 06:45:52 [7833] ERROR:rls:parse_subs_state: terminated state and no reason foundJan 20 06:45:52 [7833] ERROR:rls:rls_handle_notify: while parsing 'Subscription-State' header
Jan 20 06:46:13 [7834] ERROR:core:db_do_insert: invalid parameter value
Jan 20 06:46:13 [7834] ERROR:pua:db_update: while inserting in db table pua
Jan 20 06:46:43 [7834] ERROR:core:parse_uri: uri too short: <> (0)
Jan 20 06:46:43 [7834] ERROR:tm:uri2proxy: bad_uri:
Jan 20 06:46:43 [7834] ERROR:tm:uri2su: failed create a dst proxy
Jan 20 06:46:43 [7834] ERROR:tm:t_uac: no socket found
Jan 20 06:46:43 [7834] ERROR:pua:update_pua: in t_request function
Jan 20 06:46:43 [7834] ERROR:pua:hashT_clean: while updating record
Jan 20 06:47:05 [7833] ERROR:rls:parse_subs_state: terminated state and no reason foundJan 20 06:47:05 [7833] ERROR:rls:rls_handle_notify: while parsing 'Subscription-State' header

Regards,
rmnathan


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

Comment By: Nathan (rmnathan)
Date: 2009-02-02 14:44

Message:
Hi Anca.
Yes, am using opensips as presence server and rls server. Please find the
logs and pcap file for call flow attached.

Regards,
rmnathan


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

Comment By: Anca Vamanu (anca_vamanu)
Date: 2009-01-22 18:55

Message:
Hi rmnathan,

Thank you for this report also.
There is something wrong with that Notify that gives this error.
Can you please trace the trafic and catch a Notify that generates this
error and print it here?
This Notify is received from the presence server. Are you using also
OpenSIPS as the presence server? Can you please check is the source IP
address of the Notify message is that of the presence server?

regards,
Anca

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

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


From bogdan at voice-system.ro  Mon Feb  2 13:36:56 2009
From: bogdan at voice-system.ro (Bogdan-Andrei Iancu)
Date: Mon, 02 Feb 2009 12:36:56 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[5237] trunk
Message-ID: <E1LTy2q-0000Ec-Ga@dn4whf1.ch3.sourceforge.com>

Revision: 5237
          http://opensips.svn.sourceforge.net/opensips/?rev=5237&view=rev
Author:   bogdan_iancu
Date:     2009-02-02 12:36:53 +0000 (Mon, 02 Feb 2009)

Log Message:
-----------
- the alias core manager (handling naming aliases from script) has an API that allows other modules to register custom functions for checking if an name is alias or not

Modified Paths:
--------------
    trunk/name_alias.h

Added Paths:
-----------
    trunk/name_alias.c


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


From bogdan at voice-system.ro  Mon Feb  2 13:38:36 2009
From: bogdan at voice-system.ro (Bogdan-Andrei Iancu)
Date: Mon, 02 Feb 2009 12:38:36 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[5238] trunk/name_alias.c
Message-ID: <E1LTy4S-0000Gw-Fy@dn4whf1.ch3.sourceforge.com>

Revision: 5238
          http://opensips.svn.sourceforge.net/opensips/?rev=5238&view=rev
Author:   bogdan_iancu
Date:     2009-02-02 12:38:33 +0000 (Mon, 02 Feb 2009)

Log Message:
-----------
SVN ID prop added

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

Property Changed:
----------------
    trunk/name_alias.c


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


From bogdan at voice-system.ro  Mon Feb  2 13:40:11 2009
From: bogdan at voice-system.ro (Bogdan-Andrei Iancu)
Date: Mon, 02 Feb 2009 12:40:11 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[5239]
	trunk/modules/domain/domain_mod.c
Message-ID: <E1LTy5z-0000In-0o@dn4whf1.ch3.sourceforge.com>

Revision: 5239
          http://opensips.svn.sourceforge.net/opensips/?rev=5239&view=rev
Author:   bogdan_iancu
Date:     2009-02-02 12:40:10 +0000 (Mon, 02 Feb 2009)

Log Message:
-----------
- domain module registers the "is_local_domain" function as alias checking function to core.

Modified Paths:
--------------
    trunk/modules/domain/domain_mod.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 Feb  2 13:51:19 2009
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 02 Feb 2009 12:51:19 +0000
Subject: [OpenSIPS-Devel] [ opensips-Bugs-2166305 ] mi_fifo: opensips_fifo
	removed by 'opensips -c'
Message-ID: <E1LTyGl-0003J9-Dd@665xhf1.ch3.sourceforge.com>

Bugs item #2166305, was opened at 2008-10-14 18:20
Message generated for change (Settings changed) made by bogdan_iancu
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=2166305&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.4.x
Status: Open
>Resolution: Fixed
Priority: 9
Private: No
Submitted By: Ovidiu Sas (osas)
Assigned to: Bogdan-Andrei Iancu (bogdan_iancu)
Summary: mi_fifo: opensips_fifo removed by 'opensips -c'

Initial Comment:
If opensips is up and running and at the same time 'opensips -c' is run in order to check a new config, if errors are detected in the new config, the opensisps_fifo file is removed.

Note: The error in the config must be detected after the mi_fifo module was loaded successfully.

Note: The mi_datagram may exposed the same issue (if run in unix file socket mode).


Regards,
Ovidiu Sas

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

>Comment By: Bogdan-Andrei Iancu (bogdan_iancu)
Date: 2009-02-02 14:51

Message:
Hi Ovidiu,

A fix is available on SVN trunk - please test and if ok, I will do the
backport.

Thanks and regards,
Bogdan

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

Comment By: Bogdan-Andrei Iancu (bogdan_iancu)
Date: 2008-10-15 10:44

Message:
Hi Ovidiu,

I agree with you - cfg file checking should not affect the existing
resources.

Regards,
Bogdan

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

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


From bogdan at voice-system.ro  Mon Feb  2 13:51:26 2009
From: bogdan at voice-system.ro (Bogdan-Andrei Iancu)
Date: Mon, 02 Feb 2009 12:51:26 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[5240] trunk/main.c
Message-ID: <E1LTyGs-0000Vo-7R@dn4whf1.ch3.sourceforge.com>

Revision: 5240
          http://opensips.svn.sourceforge.net/opensips/?rev=5240&view=rev
Author:   bogdan_iancu
Date:     2009-02-02 12:51:23 +0000 (Mon, 02 Feb 2009)

Log Message:
-----------
- do not destroy modules if not initialized - module resorces may get lost (fifo files, sockets, etc). 
Side efect of this bug: If opensips is up and running and at the same time 'opensips -c' is run in order to check a new config, if errors are detected in the new config, the opensisps_fifo file is removed.

Closes bug 2166305.

Modified Paths:
--------------
    trunk/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  Mon Feb  2 13:54:21 2009
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 02 Feb 2009 12:54:21 +0000
Subject: [OpenSIPS-Devel] [ opensips-Feature Requests-2172080 ] [Drouting]
	destination detection
Message-ID: <E1LTyJh-0003p5-96@b55xhf1.ch3.sourceforge.com>

Feature Requests item #2172080, was opened at 2008-10-16 18:41
Message generated for change (Settings changed) made by bogdan_iancu
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086413&aid=2172080&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
Priority: 5
Private: No
Submitted By: Bogdan-Andrei Iancu (bogdan_iancu)
Assigned to: Bogdan-Andrei Iancu (bogdan_iancu)
Summary: [Drouting] destination detection

Initial Comment:
Add a to_gw() function.

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

>Comment By: Bogdan-Andrei Iancu (bogdan_iancu)
Date: 2009-02-02 14:54

Message:
This is already done. Part of larger set of changes on the DR module. See:
   http://lists.opensips.org/pipermail/users/2009-January/002622.html

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

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


From noreply at sourceforge.net  Mon Feb  2 14:56:49 2009
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 02 Feb 2009 13:56:49 +0000
Subject: [OpenSIPS-Devel] [ opensips-Bugs-2557032 ] Bug: opensipsctl script
	with Postgres
Message-ID: <E1LTzI9-0003dS-4U@155xhf1.ch3.sourceforge.com>

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

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: tools
Group: 1.4.x
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: David Roberge (xittel)
Assigned to: Nobody/Anonymous (nobody)
Summary: Bug: opensipsctl script with Postgres

Initial Comment:
Hi, 
 
I am using OpenSIPS 1.4.4 with Postgres 8.3 and I am running into two problems with the opensipsctl script. 
 
1. It seems that Postgres does not support the CONCAT SQL function. I had to remove all CONCAT function calls from the script and replace them with || operators in order to use the script properly. 
 
2. I also encountered a problem when adding subscribers via the opensipsctl script. Before adding new subscriber, the script checks that no alias with the same name as the new subscriber exists in the DB. However, the script seems to be written with MySql in mind. The check_db_alias() function does not process the output of psql properly and thinks that an alias already exists. 
 
The script thinks that the last line of the output of psql contains the number of returned records. It thus set the $CNT variable to the value of the last line of the output. However, the last line is a blank line. Since the $CNT variable is set to blank, it is therefore != 0. The $ALIAS_DB_EXISTS variable is set to 1 and the script thinks that an alias exists even thought it does not. This prevents the addition of new subscribers into the DB. 
 
 
See below for the function code. 
 
---------------------------------------------- 
check_db_alias() { 
require_dbengine 
 
ALIAS_DB_EXISTS=0 
 
QUERY="select count(*) from $DA_TABLE where $DA_ALIAS_USER_COLUMN='$1' \ 
and $DA_ALIAS_DOMAIN_COLUMN='$2';" 
CNT=`$DBROCMD "$QUERY" | $EGREP -v ERROR | $LAST_LINE` 
mdbg "check_db_alias: alias counter=$CNT" 
if [ "$CNT" = "0" ] ; then 
ALIAS_DB_EXISTS=0 
else 
#ALIAS_DB_EXISTS=1 
ALIAS_DB_EXISTS=0 
fi 
} 
---------------------------------------------- 
 
 
and the actual output of the PSQL query: 
 
---------------------------------------------- 
count 
------- 
0 
(1 row) 
 
---------------------------------------------- 
 
I patched the script to force the $ALIAS_DB_EXISTS to 0 but the alias check is no more performed. 
 
Thanks. 
 
David


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

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


From bogdan at voice-system.ro  Mon Feb  2 19:54:24 2009
From: bogdan at voice-system.ro (Bogdan-Andrei Iancu)
Date: Mon, 02 Feb 2009 20:54:24 +0200
Subject: [OpenSIPS-Devel] [NEW] domain module exports stored domains as
	aliases
Message-ID: <49874160.7060508@voice-system.ro>

Hi,

An older problem was finally fixed in OpenSIPS 1.5 - the Domain module 
is automatically exporting the provisioned domains as aliases to the 
OpenSIPS core.

This is highly needed as there are other modules (or script functions 
exported by core) which needs to know what are all the local domains. 
Modules like RR (Record Route) which needs to identify the "Route" 
pointing to any of the local domains.

This solves the problem of properly detecting Pre-loaded routes which 
uses domain names (very popular) instead of IPs.


Right now we can say we have 100% complete multi-domain support in 
OpenSIPS - there is no need anymore to list the supported domains as 
aliases in script. Everything can be easyly provisioned via the domain 
module.

Regards,
Bogdan


From noreply at sourceforge.net  Mon Feb  2 23:57:32 2009
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 02 Feb 2009 22:57:32 +0000
Subject: [OpenSIPS-Devel] [ opensips-Bugs-2558584 ] broken prepared
	statements in mysql / siptrace
Message-ID: <E1LU7jQ-0004BX-3d@cdv4jf1.ch3.sourceforge.com>

Bugs item #2558584, was opened at 2009-02-02 22:57
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=2558584&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: broken prepared statements in mysql / siptrace

Initial Comment:
Recent commits to the devel/head version of OpenSIPS 1.5 have broken my sip trace. I believe this is due to new prepared statement functionality included with the db_mysql module.

Below is a except from syslog

Feb  2 16:23:43 sip opensips[10558]: DBG:siptrace:trace_onreply_out: storing info... 
Feb  2 16:23:43 sip opensips[10558]: DBG:db_mysql:has_stmt_ctx: ctx found for sip_trace 
Feb  2 16:23:43 sip opensips[10558]: DBG:db_mysql:db_mysql_do_prepared_query: set values for the statement run 
Feb  2 16:23:43 sip opensips[10558]: ERROR:db_mysql:db_mysql_val2str_nq: destination buffer too short 
Feb  2 16:23:43 sip opensips[10558]: ERROR:db_mysql:db_mysql_do_prepared_query: val2str() failed for i=0 (1) 
Feb  2 16:23:43 sip opensips[10558]: ERROR:siptrace:trace_onreply_out: error storing trace 


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

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


From gpa at appearnetworks.com  Tue Feb  3 10:31:29 2009
From: gpa at appearnetworks.com (Georgios Panagiotou)
Date: Tue, 3 Feb 2009 10:31:29 +0100
Subject: [OpenSIPS-Devel] xcap-change and support for xcap-diff-event
Message-ID: <85d10ad50902030131n6b3213fw826ad2049a26b054@mail.gmail.com>

Hello,

While searching for xcap-diff-event [1] support by opensips, I found
the following definition in <opensips_root>/parser/parse_event.h

#define PRES_XCAP_CHANGE_STR "xcap-change"
#define PRES_XCAP_CHANGE_STR_LEN 11

It seemed to me something similar to what I was looking for so I
investigated i bit more to find out what these declarations stand for.
However, I couldnt find a module using these declarations (i.e. like
the presence one). It also seems that these declarations (which are
maybe for the support of the I-D xcap-change-log [2]) appear in the
openser project as well (I checked on openser version 1.3.1 and they
exist there as well, so there are maybe before the branching of the
projects). Can you elaborate a bit on the issue (where these
definitions are used, if used)?

Finally, I would like to ask if there is planned support for [1],
since I think that there is a lot of code that could be reused (i.e.
in presence, rls, etc.) to integrate this I-D, and I am in the process
of starting doing so.

BR,

/Giorgos Panagiotou

[1] An Extensible Markup Language (XML) Configuration Access Protocol
(XCAP) Diff Event Package,
http://tools.ietf.org/html/draft-ietf-sip-xcapevent-04 , Expires April
6 2009

[2] An XML Format for Representing XML Configuration Access Protocol
(XCAP) Change Logs, draft-rosenberg-simple-xcap-change-log-00 ,
Expired


From bogdan at voice-system.ro  Tue Feb  3 10:58:04 2009
From: bogdan at voice-system.ro (Bogdan-Andrei Iancu)
Date: Tue, 03 Feb 2009 11:58:04 +0200
Subject: [OpenSIPS-Devel] On the edge of a new major release
Message-ID: <4988152C.8020905@voice-system.ro>


As the work for the new OpenSIPS major release (OpenSIPS 1.5.0), the 
question is: What is new in 1.5.0, what was changed, what was enhanced ?

Now you can find the answers to all this question is this comprehensive 
compilation of OpenSIPS evolution from 1.4.0 to 1.5.0:
    http://www.opensips.org/index.php?n=Main.Ver15x

There are some other pending contributions which are not listed there - 
contributions from new OpenSIPS developers. We are still working on the 
integration part.

Best regards,
Bogdan


From noreply at sourceforge.net  Tue Feb  3 11:06:14 2009
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 03 Feb 2009 10:06:14 +0000
Subject: [OpenSIPS-Devel] [ opensips-Bugs-2558584 ] broken prepared
	statements in mysql / siptrace
Message-ID: <E1LUIAY-0001Ae-C4@1bkjzd1.ch3.sourceforge.com>

Bugs item #2558584, was opened at 2009-02-03 00:57
Message generated for change (Settings changed) made by bogdan_iancu
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=2558584&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: Accepted
Priority: 5
Private: No
Submitted By: Nobody/Anonymous (nobody)
>Assigned to: Bogdan-Andrei Iancu (bogdan_iancu)
Summary: broken prepared statements in mysql / siptrace

Initial Comment:
Recent commits to the devel/head version of OpenSIPS 1.5 have broken my sip trace. I believe this is due to new prepared statement functionality included with the db_mysql module.

Below is a except from syslog

Feb  2 16:23:43 sip opensips[10558]: DBG:siptrace:trace_onreply_out: storing info... 
Feb  2 16:23:43 sip opensips[10558]: DBG:db_mysql:has_stmt_ctx: ctx found for sip_trace 
Feb  2 16:23:43 sip opensips[10558]: DBG:db_mysql:db_mysql_do_prepared_query: set values for the statement run 
Feb  2 16:23:43 sip opensips[10558]: ERROR:db_mysql:db_mysql_val2str_nq: destination buffer too short 
Feb  2 16:23:43 sip opensips[10558]: ERROR:db_mysql:db_mysql_do_prepared_query: val2str() failed for i=0 (1) 
Feb  2 16:23:43 sip opensips[10558]: ERROR:siptrace:trace_onreply_out: error storing trace 


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

>Comment By: Bogdan-Andrei Iancu (bogdan_iancu)
Date: 2009-02-03 12:06

Message:
Indeed, the problem seems to be the too short val buffer used for preparing
the statement - I will investigate the possibility of increasing the buffer
and what are the possible side effects for it. If not possible, I will
disable the prepared statements for the siptrace module as this module is
using large amount of date to transfer to DB (the sip messages).

Thanks and regards,
Bogdan

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

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


From noreply at sourceforge.net  Tue Feb  3 12:01:13 2009
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 03 Feb 2009 11:01:13 +0000
Subject: [OpenSIPS-Devel] [ opensips-Feature Requests-2560375 ] Increase
	SysLog Verbosity
Message-ID: <E1LUJ1l-0006Xi-3y@3bkjzd1.ch3.sourceforge.com>

Feature Requests item #2560375, was opened at 2009-02-03 11:01
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086413&aid=2560375&group_id=232389

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

Initial Comment:
Simplify reading of the OpenSIPS log via syslog by introducing more Verbosity when OpenSIPS 'Send' msgs.

This should help troubleshooting immensely.

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

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


From bogdan at voice-system.ro  Tue Feb  3 12:21:48 2009
From: bogdan at voice-system.ro (Bogdan-Andrei Iancu)
Date: Tue, 03 Feb 2009 11:21:48 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[5241] trunk/modules/registrar
Message-ID: <E1LUJLg-0001Bh-UL@c3vjzd1.ch3.sourceforge.com>

Revision: 5241
          http://opensips.svn.sourceforge.net/opensips/?rev=5241&view=rev
Author:   bogdan_iancu
Date:     2009-02-03 11:21:46 +0000 (Tue, 03 Feb 2009)

Log Message:
-----------
- registered() function can be now used from ONREPLY route, BRANCH route and LOCAL route.
  Based on an idea from Sebastian Schumann.

Modified Paths:
--------------
    trunk/modules/registrar/README
    trunk/modules/registrar/doc/registrar_admin.xml
    trunk/modules/registrar/lookup.c
    trunk/modules/registrar/reg_mod.c


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


From bogdan at voice-system.ro  Tue Feb  3 12:51:16 2009
From: bogdan at voice-system.ro (Bogdan-Andrei Iancu)
Date: Tue, 03 Feb 2009 11:51:16 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[5242] trunk/modules/tm
Message-ID: <E1LUJoC-0005JK-Ht@bj8yhf1.ch3.sourceforge.com>

Revision: 5242
          http://opensips.svn.sourceforge.net/opensips/?rev=5242&view=rev
Author:   bogdan_iancu
Date:     2009-02-03 11:51:16 +0000 (Tue, 03 Feb 2009)

Log Message:
-----------
- new PV exported by the module:
 
 $T_ruri - the ruri of the current branch; this nformation is taken from the transaction structure, so you can access this information for any sip message (request/reply) that has a transaction.

Modified Paths:
--------------
    trunk/modules/tm/README
    trunk/modules/tm/doc/tm_admin.xml
    trunk/modules/tm/tm.c


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


From ptdamore at gmail.com  Tue Feb  3 15:32:06 2009
From: ptdamore at gmail.com (Phil D'Amore)
Date: Tue, 3 Feb 2009 09:32:06 -0500
Subject: [OpenSIPS-Devel] Change to listen= syntax to support per-interface
	advertised address...
Message-ID: <30b4f6c70902030632o256b4860x9cea72141b59ea77@mail.gmail.com>

Hello:

A while back (around openser 1.3 time) I tried to get some feedback
for this functionality that I've been using for a while.  Now that I'm
having to port it to opensips 1.5.0 I figured I'd try to put it out
here and see what happens:

The patch extends the idea of the advertised_address and advertised_port
parameters so that it is possible to bind such an address to each
listen= statement.
Syntax-wise, it works like this:

   listen=[proto:]host[:port][ AS host[:port]]

This new AS host[:port] syntax binds the advertised address specifically to the
corresponding socket_info structure.  If such an address is specified, it will
be used before the address specified as advertised_address, or set in the
set_advertised_address function for packets being sent on that particular
socket.  If it is not specified, then the old methods work as before.

The core has been modified so that address tuples using the advertised address
work interchangeably with the real address where you'd expect them to.
grep_sock_info and find_si have been updated to allow this.  Therefore, it is
not necessary to explicitly name your advertised address on an alias= line.
The following are now equivalent:

   force_send_socket(udp:adv_address:adv_port);
   force_send_socket(udp:real_address:real_port);

Note we don't specify protocol on the advertised address.  The way I see
things, it makes no sense to advertise a different protocol, so it inherits the
protocol of the socket.

Via construction is affected in the same way that the old global
advertised_address does, except the Via is written specifically for
the socket used
to send the message.

Lump substitution is also affected.  The following lump substitutions are aware
of this new facility:

 SUBST_RCV_IP
 SUBST_RCV_PORT
 SUBST_RCV_ALL
 SUBST_SND_IP
 SUBST_SND_PORT
 SUBST_SND_ALL

As a result of this, I was able to stop using record_route_preset in
my own config, and
just use standard record_route.  This winds up working much better,
because double-rr
works properly, and add_rr_param now works as expected for me, where it was a
problem using record_route_preset.

Additionally, registrar and usrloc had to be modified:

registrar - update the add_sock_hdr function to put the advertised address in
the message instead of the real address.  This allows registration information
to be replicated between multi-homed proxies, and the correct interface on the
peer can be used.

usrloc - update db_insert_ucontact to store the advertised address in the
database instead of the real address.  Same reasoning as the mods to registrar.

If there's any interest, I can submit a patch and more details about
how it works.

Thanks,
Phil


From noreply at sourceforge.net  Tue Feb  3 16:52:21 2009
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 03 Feb 2009 15:52:21 +0000
Subject: [OpenSIPS-Devel] [ opensips-Patches-2561177 ] Prepared statements
	support for avpops module
Message-ID: <E1LUNZV-00052E-Aq@155xhf1.ch3.sourceforge.com>

Patches item #2561177, was opened at 2009-02-03 10:52
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086412&aid=2561177&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: Sergio Gutierrez (saguti)
Assigned to: Nobody/Anonymous (nobody)
Summary: Prepared statements support for avpops module

Initial Comment:
The patch enables prepared statements for avpops module queries.

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

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


From bogdan at voice-system.ro  Tue Feb  3 17:06:01 2009
From: bogdan at voice-system.ro (Bogdan-Andrei Iancu)
Date: Tue, 03 Feb 2009 16:06:01 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[5243]
	trunk/modules/siptrace/siptrace.c
Message-ID: <E1LUNmj-0007B2-75@d5vjzd1.ch3.sourceforge.com>

Revision: 5243
          http://opensips.svn.sourceforge.net/opensips/?rev=5243&view=rev
Author:   bogdan_iancu
Date:     2009-02-03 16:05:58 +0000 (Tue, 03 Feb 2009)

Log Message:
-----------
- temporary disabled the prepared statement due too large data chunks

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 iulia at opensips.org  Tue Feb  3 17:29:10 2009
From: iulia at opensips.org (Iulia Bublea)
Date: Tue, 03 Feb 2009 16:29:10 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[5244]
	trunk/scripts/osipsconsole
Message-ID: <E1LUO98-0007Sj-CH@d5vjzd1.ch3.sourceforge.com>

Revision: 5244
          http://opensips.svn.sourceforge.net/opensips/?rev=5244&view=rev
Author:   iulia_bublea
Date:     2009-02-03 16:29:10 +0000 (Tue, 03 Feb 2009)

Log Message:
-----------
Bug reported by Joan, regarding the connection to mysql with root and no password, was fixed.  

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


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


From bogdan at voice-system.ro  Tue Feb  3 17:39:53 2009
From: bogdan at voice-system.ro (Bogdan-Andrei Iancu)
Date: Tue, 03 Feb 2009 16:39:53 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[5245]
	trunk/modules/siptrace/siptrace.c
Message-ID: <E1LUOJV-0007ZE-11@d5vjzd1.ch3.sourceforge.com>

Revision: 5245
          http://opensips.svn.sourceforge.net/opensips/?rev=5245&view=rev
Author:   bogdan_iancu
Date:     2009-02-03 16:39:52 +0000 (Tue, 03 Feb 2009)

Log Message:
-----------
- related to prev commit

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 dan at ag-projects.com  Tue Feb  3 19:14:09 2009
From: dan at ag-projects.com (Dan Pascu)
Date: Tue, 3 Feb 2009 20:14:09 +0200
Subject: [OpenSIPS-Devel] xcap-change and support for xcap-diff-event
In-Reply-To: <85d10ad50902030131n6b3213fw826ad2049a26b054@mail.gmail.com>
References: <85d10ad50902030131n6b3213fw826ad2049a26b054@mail.gmail.com>
Message-ID: <200902032014.09505.dan@ag-projects.com>


There is the presence_xcapdiff module.

On Tuesday 03 February 2009, Georgios Panagiotou wrote:
> Hello,
>
> While searching for xcap-diff-event [1] support by opensips, I found
> the following definition in <opensips_root>/parser/parse_event.h
>
> #define PRES_XCAP_CHANGE_STR "xcap-change"
> #define PRES_XCAP_CHANGE_STR_LEN 11
>
> It seemed to me something similar to what I was looking for so I
> investigated i bit more to find out what these declarations stand for.
> However, I couldnt find a module using these declarations (i.e. like
> the presence one). It also seems that these declarations (which are
> maybe for the support of the I-D xcap-change-log [2]) appear in the
> openser project as well (I checked on openser version 1.3.1 and they
> exist there as well, so there are maybe before the branching of the
> projects). Can you elaborate a bit on the issue (where these
> definitions are used, if used)?
>
> Finally, I would like to ask if there is planned support for [1],
> since I think that there is a lot of code that could be reused (i.e.
> in presence, rls, etc.) to integrate this I-D, and I am in the process
> of starting doing so.
>
> BR,
>
> /Giorgos Panagiotou
>
> [1] An Extensible Markup Language (XML) Configuration Access Protocol
> (XCAP) Diff Event Package,
> http://tools.ietf.org/html/draft-ietf-sip-xcapevent-04 , Expires April
> 6 2009
>
> [2] An XML Format for Representing XML Configuration Access Protocol
> (XCAP) Change Logs, draft-rosenberg-simple-xcap-change-log-00 ,
> Expired
>
> _______________________________________________
> Devel mailing list
> Devel at lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/devel



-- 
Dan


From bogdan at voice-system.ro  Wed Feb  4 10:28:01 2009
From: bogdan at voice-system.ro (Bogdan-Andrei Iancu)
Date: Wed, 04 Feb 2009 09:28:01 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[5246]
	trunk/modules/tm/t_reply.c
Message-ID: <E1LUe37-00015H-Qq@3kljzd1.ch3.sourceforge.com>

Revision: 5246
          http://opensips.svn.sourceforge.net/opensips/?rev=5246&view=rev
Author:   bogdan_iancu
Date:     2009-02-04 09:28:01 +0000 (Wed, 04 Feb 2009)

Log Message:
-----------
- fixed availability of branch index in onreply route and failure route

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


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


From bogdan at voice-system.ro  Wed Feb  4 10:35:39 2009
From: bogdan at voice-system.ro (Bogdan-Andrei Iancu)
Date: Wed, 04 Feb 2009 09:35:39 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[5247]
	branches/1.4/modules/tm/t_reply.c
Message-ID: <E1LUeAV-00019A-6a@3kljzd1.ch3.sourceforge.com>

Revision: 5247
          http://opensips.svn.sourceforge.net/opensips/?rev=5247&view=rev
Author:   bogdan_iancu
Date:     2009-02-04 09:35:38 +0000 (Wed, 04 Feb 2009)

Log Message:
-----------
backport from trunk (rev 5246):
- fixed availability of branch index in onreply route and failure route

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

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


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


From bogdan at voice-system.ro  Wed Feb  4 10:53:07 2009
From: bogdan at voice-system.ro (Bogdan-Andrei Iancu)
Date: Wed, 04 Feb 2009 09:53:07 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[5248]
	trunk/modules/db_mysql/val.c
Message-ID: <E1LUeRP-0001Gi-Ch@3kljzd1.ch3.sourceforge.com>

Revision: 5248
          http://opensips.svn.sourceforge.net/opensips/?rev=5248&view=rev
Author:   bogdan_iancu
Date:     2009-02-04 09:53:07 +0000 (Wed, 04 Feb 2009)

Log Message:
-----------
- do not escape anymore the strings used in prepared statements as it is useless -> this is a huge boost in performance.
Next step: avoid copying the string buffers

Modified Paths:
--------------
    trunk/modules/db_mysql/val.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 Feb  4 15:23:49 2009
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 04 Feb 2009 14:23:49 +0000
Subject: [OpenSIPS-Devel] [ opensips-Patches-2564149 ] mysql performance
	enhancements
Message-ID: <E1LUifN-0004nJ-7V@b55xhf1.ch3.sourceforge.com>

Patches item #2564149, was opened at 2009-02-04 09:23
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086412&aid=2564149&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: Unix Dev (psystar)
Assigned to: Nobody/Anonymous (nobody)
Summary: mysql performance enhancements

Initial Comment:
Changed all mysql types from varchar to char in order to change table type from 'dynamic' to 'fixed'. Note, some tables are still dynamic due to specific data types, blob, text, etc.

Version numbers for tables have been incremented.

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

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


From noreply at sourceforge.net  Wed Feb  4 19:57:23 2009
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 04 Feb 2009 18:57:23 +0000
Subject: [OpenSIPS-Devel] [ opensips-Bugs-2558584 ] broken prepared
	statements in mysql / siptrace
Message-ID: <E1LUmw7-0003lN-L5@g45xhf1.ch3.sourceforge.com>

Bugs item #2558584, was opened at 2009-02-03 00:57
Message generated for change (Settings changed) made by bogdan_iancu
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=2558584&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: Nobody/Anonymous (nobody)
Assigned to: Bogdan-Andrei Iancu (bogdan_iancu)
Summary: broken prepared statements in mysql / siptrace

Initial Comment:
Recent commits to the devel/head version of OpenSIPS 1.5 have broken my sip trace. I believe this is due to new prepared statement functionality included with the db_mysql module.

Below is a except from syslog

Feb  2 16:23:43 sip opensips[10558]: DBG:siptrace:trace_onreply_out: storing info... 
Feb  2 16:23:43 sip opensips[10558]: DBG:db_mysql:has_stmt_ctx: ctx found for sip_trace 
Feb  2 16:23:43 sip opensips[10558]: DBG:db_mysql:db_mysql_do_prepared_query: set values for the statement run 
Feb  2 16:23:43 sip opensips[10558]: ERROR:db_mysql:db_mysql_val2str_nq: destination buffer too short 
Feb  2 16:23:43 sip opensips[10558]: ERROR:db_mysql:db_mysql_do_prepared_query: val2str() failed for i=0 (1) 
Feb  2 16:23:43 sip opensips[10558]: ERROR:siptrace:trace_onreply_out: error storing trace 


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

Comment By: Bogdan-Andrei Iancu (bogdan_iancu)
Date: 2009-02-03 12:06

Message:
Indeed, the problem seems to be the too short val buffer used for preparing
the statement - I will investigate the possibility of increasing the buffer
and what are the possible side effects for it. If not possible, I will
disable the prepared statements for the siptrace module as this module is
using large amount of date to transfer to DB (the sip messages).

Thanks and regards,
Bogdan

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

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


From noreply at sourceforge.net  Wed Feb  4 19:58:45 2009
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 04 Feb 2009 18:58:45 +0000
Subject: [OpenSIPS-Devel] [ opensips-Patches-2564149 ] mysql performance
	enhancements
Message-ID: <E1LUmxR-00069M-Ok@665xhf1.ch3.sourceforge.com>

Patches item #2564149, was opened at 2009-02-04 16:23
Message generated for change (Settings changed) made by bogdan_iancu
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086412&aid=2564149&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: Unix Dev (psystar)
>Assigned to: Bogdan-Andrei Iancu (bogdan_iancu)
Summary: mysql performance enhancements

Initial Comment:
Changed all mysql types from varchar to char in order to change table type from 'dynamic' to 'fixed'. Note, some tables are still dynamic due to specific data types, blob, text, etc.

Version numbers for tables have been incremented.

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

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


From noreply at sourceforge.net  Wed Feb  4 19:59:06 2009
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 04 Feb 2009 18:59:06 +0000
Subject: [OpenSIPS-Devel] [ opensips-Patches-2561177 ] Prepared statements
	support for avpops module
Message-ID: <E1LUmxm-0003tu-Oz@g45xhf1.ch3.sourceforge.com>

Patches item #2561177, was opened at 2009-02-03 17:52
Message generated for change (Settings changed) made by bogdan_iancu
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086412&aid=2561177&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: Sergio Gutierrez (saguti)
>Assigned to: Bogdan-Andrei Iancu (bogdan_iancu)
Summary: Prepared statements support for avpops module

Initial Comment:
The patch enables prepared statements for avpops module queries.

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

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


From bogdan at voice-system.ro  Thu Feb  5 10:13:03 2009
From: bogdan at voice-system.ro (Bogdan-Andrei Iancu)
Date: Thu, 05 Feb 2009 11:13:03 +0200
Subject: [OpenSIPS-Devel] [OpenSIPS-Users] [RFC] SIPtrace behaviour
In-Reply-To: <497EFA85.3040502@voice-system.ro>
References: <497EFA85.3040502@voice-system.ro>
Message-ID: <498AAD9F.3080805@voice-system.ro>

Hi,

Well, if there are no opinion, on this, I will add a parameter to 
control the tracing of the stateless ACKs ....by default it will disabled.

Regards,
Bogdan

Bogdan-Andrei Iancu wrote:
> Hi,
>
> While doing some work on the siptrace module I remembered some pending 
> issues in regards to sip tracing:
>
> 1) tracing the stateless ACKs - right now, all the stateless ACK (in 
> response to stateless replies) are traced ; this happens because you do 
> not get any access to the ACK (from script), so you cannot set the trace 
> flag, and also because it is stateless, so you cannot keep any state to 
> remember (at ACK time) if the ACK should or not be traced.
>
> This current behaviour is quite annoying because your siptrace DB will 
> be actually flooded with ACKs, even is you do not mark no message for 
> tracing...Personally I do disable from the code the stateless ACK 
> tracing in order to get access to only relevant data.
>
> So, the questions are:
>     1) any suggestions about how we can do selective tracing on the 
> stateless ACKs (from sl module)
>     2) should we disable it or at least make it configurable in the module?
>
>
> Regards,
> Bogdan
>
> _______________________________________________
> Users mailing list
> Users at lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>
>   



From noreply at sourceforge.net  Thu Feb  5 10:13:58 2009
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 05 Feb 2009 09:13:58 +0000
Subject: [OpenSIPS-Devel] [ opensips-Bugs-2567535 ] [register] do not update
	DB
Message-ID: <E1LV0J4-00074b-Ez@155xhf1.ch3.sourceforge.com>

Bugs item #2567535, was opened at 2009-02-05 11:13
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=2567535&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: ibrahim tunali (itunali)
Assigned to: Nobody/Anonymous (nobody)
Summary: [register] do not update DB

Initial Comment:
Register module do not update db fileds "expires" and "modified" when received re-register (refresh registering) request.

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

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


From bogdan at voice-system.ro  Thu Feb  5 10:26:25 2009
From: bogdan at voice-system.ro (Bogdan-Andrei Iancu)
Date: Thu, 05 Feb 2009 09:26:25 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[5249] trunk/modules/siptrace
Message-ID: <E1LV0V7-0005ZL-L1@bj8yhf1.ch3.sourceforge.com>

Revision: 5249
          http://opensips.svn.sourceforge.net/opensips/?rev=5249&view=rev
Author:   bogdan_iancu
Date:     2009-02-05 09:26:25 +0000 (Thu, 05 Feb 2009)

Log Message:
-----------
- new parameter to control the tracing of the stateless ACK.
    "enable_ack_trace" - default disabled.
See http://lists.opensips.org/pipermail/users/2009-January/002769.html

Modified Paths:
--------------
    trunk/modules/siptrace/README
    trunk/modules/siptrace/doc/siptrace_admin.xml
    trunk/modules/siptrace/siptrace.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 Feb  5 12:52:19 2009
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 05 Feb 2009 11:52:19 +0000
Subject: [OpenSIPS-Devel] [ opensips-Bugs-2567535 ] [register] do not update
	DB
Message-ID: <E1LV2mJ-000101-T2@d55xhf1.ch3.sourceforge.com>

Bugs item #2567535, was opened at 2009-02-05 11:13
Message generated for change (Comment added) made by itunali
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=2567535&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: Deleted
>Resolution: Duplicate
Priority: 5
Private: No
Submitted By: ibrahim tunali (itunali)
Assigned to: Nobody/Anonymous (nobody)
Summary: [register] do not update DB

Initial Comment:
Register module do not update db fileds "expires" and "modified" when received re-register (refresh registering) request.

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

>Comment By: ibrahim tunali (itunali)
Date: 2009-02-05 13:52

Message:
I have already post this issue to mail list

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

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


From bogdan at voice-system.ro  Thu Feb  5 13:04:53 2009
From: bogdan at voice-system.ro (Bogdan-Andrei Iancu)
Date: Thu, 05 Feb 2009 12:04:53 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[5250] trunk/modules/db_mysql
Message-ID: <E1LV2yT-0001Gl-5g@c3vjzd1.ch3.sourceforge.com>

Revision: 5250
          http://opensips.svn.sourceforge.net/opensips/?rev=5250&view=rev
Author:   bogdan_iancu
Date:     2009-02-05 12:04:52 +0000 (Thu, 05 Feb 2009)

Log Message:
-----------
several improvments in prepared statements code:

1) push in mysql directly the data provided from application layer (modules using DB) - no copy, no conversion, not nothing. This gives a huge boost on processing strings, intergers and large BLOBS

2) no limititation for the data size that needs to be pushed into DB

Modified Paths:
--------------
    trunk/modules/db_mysql/dbase.c
    trunk/modules/db_mysql/my_con.h
    trunk/modules/db_mysql/val.c
    trunk/modules/db_mysql/val.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 Feb  5 13:08:46 2009
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 05 Feb 2009 12:08:46 +0000
Subject: [OpenSIPS-Devel] [ opensips-Bugs-2558584 ] broken prepared
	statements in mysql / siptrace
Message-ID: <E1LV32E-0002Ov-RQ@565xhf1.ch3.sourceforge.com>

Bugs item #2558584, was opened at 2009-02-03 00:57
Message generated for change (Comment added) made by bogdan_iancu
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=2558584&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: Nobody/Anonymous (nobody)
Assigned to: Bogdan-Andrei Iancu (bogdan_iancu)
Summary: broken prepared statements in mysql / siptrace

Initial Comment:
Recent commits to the devel/head version of OpenSIPS 1.5 have broken my sip trace. I believe this is due to new prepared statement functionality included with the db_mysql module.

Below is a except from syslog

Feb  2 16:23:43 sip opensips[10558]: DBG:siptrace:trace_onreply_out: storing info... 
Feb  2 16:23:43 sip opensips[10558]: DBG:db_mysql:has_stmt_ctx: ctx found for sip_trace 
Feb  2 16:23:43 sip opensips[10558]: DBG:db_mysql:db_mysql_do_prepared_query: set values for the statement run 
Feb  2 16:23:43 sip opensips[10558]: ERROR:db_mysql:db_mysql_val2str_nq: destination buffer too short 
Feb  2 16:23:43 sip opensips[10558]: ERROR:db_mysql:db_mysql_do_prepared_query: val2str() failed for i=0 (1) 
Feb  2 16:23:43 sip opensips[10558]: ERROR:siptrace:trace_onreply_out: error storing trace 


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

>Comment By: Bogdan-Andrei Iancu (bogdan_iancu)
Date: 2009-02-05 14:08

Message:
OK - the prepared statements accepts now any data size, so, it shouldn't be
a problem anymore.

Thanks and regards,
Bogdan

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

Comment By: Bogdan-Andrei Iancu (bogdan_iancu)
Date: 2009-02-03 12:06

Message:
Indeed, the problem seems to be the too short val buffer used for preparing
the statement - I will investigate the possibility of increasing the buffer
and what are the possible side effects for it. If not possible, I will
disable the prepared statements for the siptrace module as this module is
using large amount of date to transfer to DB (the sip messages).

Thanks and regards,
Bogdan

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

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


From bogdan at voice-system.ro  Thu Feb  5 13:09:42 2009
From: bogdan at voice-system.ro (Bogdan-Andrei Iancu)
Date: Thu, 05 Feb 2009 12:09:42 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[5251]
	trunk/modules/siptrace/siptrace.c
Message-ID: <E1LV338-0001JU-GT@c3vjzd1.ch3.sourceforge.com>

Revision: 5251
          http://opensips.svn.sourceforge.net/opensips/?rev=5251&view=rev
Author:   bogdan_iancu
Date:     2009-02-05 12:09:42 +0000 (Thu, 05 Feb 2009)

Log Message:
-----------
- prepared statements enabled back as the fixes in mysql module allow transfer of large data chuncks

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 noreply at sourceforge.net  Thu Feb  5 13:58:05 2009
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 05 Feb 2009 12:58:05 +0000
Subject: [OpenSIPS-Devel] [ opensips-Patches-2561177 ] Prepared statements
	support for avpops module
Message-ID: <E1LV3nx-0005mF-4g@1bkjzd1.ch3.sourceforge.com>

Patches item #2561177, was opened at 2009-02-03 17:52
Message generated for change (Settings changed) made by bogdan_iancu
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086412&aid=2561177&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: Sergio Gutierrez (saguti)
Assigned to: Bogdan-Andrei Iancu (bogdan_iancu)
Summary: Prepared statements support for avpops module

Initial Comment:
The patch enables prepared statements for avpops module queries.

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

>Comment By: Bogdan-Andrei Iancu (bogdan_iancu)
Date: 2009-02-05 14:58

Message:
Hi Sergio,

This is not correct as the query is not all the time the same (as format)
- this is mandatory for prepared statements. As you can see, the query may
have different number of selected row and different number of rows in where
statement.

Regards,
Bogdan

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

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


From bogdan at voice-system.ro  Thu Feb  5 22:40:36 2009
From: bogdan at voice-system.ro (Bogdan-Andrei Iancu)
Date: Thu, 05 Feb 2009 23:40:36 +0200
Subject: [OpenSIPS-Devel] [NEW] Database enhancements,
	a 25% performance boost
Message-ID: <498B5CD4.7070308@voice-system.ro>

Hi,

Part of the work to address the most problematic (read "slow") parts of 
OpenSIPS, several improvements were done on the DB areas (performing DB 
queries).

The end result is a 25% boost in DB queries - a 25% less time spent in 
running DB queries.


1. Prepared statements
=======================

Starting with OpenSIPS 1.5.0 the internal DB API provides support for 
prepared statements. First DB module to implement prepared statements is 
DB_MYSQL module. See more about the concept of prepared statements in 
MySQL : 
http://dev.mysql.com/doc/refman/5.0/en/sql-syntax-prepared-statements.html

A very good overview on Prepared Statements, that may help you in 
understating the advantages and disadvantages of prepared statements can 
be found at 
http://www.mysqlperformanceblog.com/2006/08/02/mysql-prepared-statements/.

The current implementation is based on an original patch submited by 
Victor Gamov; the patch was completely reworked, re-designed and improved.


2. Memory Fragmentation
========================

A complete rework of the structures from internal DB API was done in 
order to reduce the number of memory fragments used by a DB result:
    previous number = 1 + 2 + no_cols + 1 + no_rows
    current number = 3
The number of memory fragments is now constant and what is more 
important is the fact that we avoid keep allocating very small chunks 
(like 8 bytes).

This will reduce the fragmentation of the private memory due of 
continues DB queries -> OpenSIPS is now a real long distance runner, 
with no side effect or performance decrease in time.


TESTS AND MEASUREMENTS
========================

A set of tests were conducted in order to determine the real gain of 
prepared statements. The tests tried to cover various case - 
combinations between complexity of a query and the amount of data 
transfered by a query.

Following the measurement with the new prepared statements a 25 % 
increase in performance. See the entire set of tests as well as the 
result interpretation:

                
http://www.opensips.org/pmwiki.php?n=Resources.TestsPrepareStatements


Best regards,
Bogdan


From bogdan at voice-system.ro  Fri Feb  6 10:57:44 2009
From: bogdan at voice-system.ro (Bogdan-Andrei Iancu)
Date: Fri, 06 Feb 2009 09:57:44 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[5252]
	trunk/modules/group/group.c
Message-ID: <E1LVNSy-0003rM-PP@dn4whf1.ch3.sourceforge.com>

Revision: 5252
          http://opensips.svn.sourceforge.net/opensips/?rev=5252&view=rev
Author:   bogdan_iancu
Date:     2009-02-06 09:57:44 +0000 (Fri, 06 Feb 2009)

Log Message:
-----------
- fixed usage of NULL pointer

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


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


From iulia at opensips.org  Fri Feb  6 15:27:44 2009
From: iulia at opensips.org (Iulia Bublea)
Date: Fri, 06 Feb 2009 14:27:44 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[5253]
	trunk/scripts/osipsconsole
Message-ID: <E1LVRgG-00046W-79@bj8yhf1.ch3.sourceforge.com>

Revision: 5253
          http://opensips.svn.sourceforge.net/opensips/?rev=5253&view=rev
Author:   iulia_bublea
Date:     2009-02-06 14:27:44 +0000 (Fri, 06 Feb 2009)

Log Message:
-----------
Fixed bug raise by Joan regarding connection to mysql db using password.

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


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


From iulia at opensips.org  Fri Feb  6 15:29:07 2009
From: iulia at opensips.org (Iulia Bublea)
Date: Fri, 06 Feb 2009 14:29:07 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[5254]
	trunk/scripts/osipsconsole
Message-ID: <E1LVRhb-00047L-Bh@bj8yhf1.ch3.sourceforge.com>

Revision: 5254
          http://opensips.svn.sourceforge.net/opensips/?rev=5254&view=rev
Author:   iulia_bublea
Date:     2009-02-06 14:29:07 +0000 (Fri, 06 Feb 2009)

Log Message:
-----------
Fixed bug raise by Joan regarding connection to mysql db using password.

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


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


From saguti at gmail.com  Fri Feb  6 16:13:51 2009
From: saguti at gmail.com (Sergio Gutierrez)
Date: Fri, 06 Feb 2009 15:13:51 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[5255]
	trunk/modules/nathelper/doc/nathelper_admin.xml
Message-ID: <E1LVSOt-0004L3-TT@dn4whf1.ch3.sourceforge.com>

Revision: 5255
          http://opensips.svn.sourceforge.net/opensips/?rev=5255&view=rev
Author:   saguti
Date:     2009-02-06 15:13:51 +0000 (Fri, 06 Feb 2009)

Log Message:
-----------
- Missed quotes around parameter in rtpproxy_stream2xxx example.

Modified Paths:
--------------
    trunk/modules/nathelper/doc/nathelper_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 Feb  6 16:40:43 2009
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 06 Feb 2009 15:40:43 +0000
Subject: [OpenSIPS-Devel] [ opensips-Bugs-2573029 ] [trunk/r5254] crash in
	dialog/
Message-ID: <E1LVSot-0006gP-CU@b55xhf1.ch3.sourceforge.com>

Bugs item #2573029, was opened at 2009-02-06 15:40
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=2573029&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: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: [trunk/r5254] crash in dialog/

Initial Comment:
(from vasil.kolev at attractel.com)

Turns out that you can pass rpl == FAKED_REPLY (which is -1) to dlg_onreply(), which will in turn try to dereference it and crash. This fixes it for me, if you're interested, I can reproduce the core dump.

This happens when testing presence and related stuff.


--- modules/dialog/dlg_handlers.c	(revision 5254)
+++ modules/dialog/dlg_handlers.c	(working copy)
@@ -288,24 +288,29 @@
 		LM_DBG("dialog %p confirmed\n",dlg);
 
 		/* get to tag*/
-		if ( !rpl->to && ((parse_headers(rpl, HDR_TO_F,0)<0) || !rpl->to) ) {
-			LM_ERR("bad reply or missing TO hdr :-/\n");
-			tag.s = 0;
-			tag.len = 0;
-		} else {
-			tag = get_to(rpl)->tag_value;
-			if (tag.s==0 || tag.len==0) {
-				LM_ERR("missing TAG param in TO hdr :-/\n");
+		if ( rpl != FAKED_REPLY){
+			if ( !rpl->to && ((parse_headers(rpl, HDR_TO_F,0)<0) || !rpl->to) ) {
+				LM_ERR("bad reply or missing TO hdr :-/\n");
 				tag.s = 0;
 				tag.len = 0;
+			} else {
+				tag = get_to(rpl)->tag_value;
+				if (tag.s==0 || tag.len==0) {
+					LM_ERR("missing TAG param in TO hdr :-/\n");
+					tag.s = 0;
+					tag.len = 0;
+				}
 			}
+			/* save callee's tag, cseq, contact and record route*/
+			if (populate_leg_info( dlg, rpl, t, DLG_CALLEE_LEG, &tag) !=0) {
+				LM_ERR("could not add further info to the dialog\n");
+			}
+		} else {
+			LM_DBG("FAKED_REPLY detected\n");
+			tag.s = 0;
+			tag.len = 0;
 		}
 
-		/* save callee's tag, cseq, contact and record route*/
-		if (populate_leg_info( dlg, rpl, t, DLG_CALLEE_LEG, &tag) !=0) {
-			LM_ERR("could not add further info to the dialog\n");
-		}
-
 		/* set start time */
 		dlg->start_ts = (unsigned int)(time(0));
 


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

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


From iulia at opensips.org  Fri Feb  6 17:33:33 2009
From: iulia at opensips.org (Iulia Bublea)
Date: Fri, 06 Feb 2009 16:33:33 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[5256]
	trunk/scripts/osipsconsole
Message-ID: <E1LVTe1-000684-Uv@d5vjzd1.ch3.sourceforge.com>

Revision: 5256
          http://opensips.svn.sourceforge.net/opensips/?rev=5256&view=rev
Author:   iulia_bublea
Date:     2009-02-06 16:33:33 +0000 (Fri, 06 Feb 2009)

Log Message:
-----------
Fixed bug regarding DB creation.

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


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


From noreply at sourceforge.net  Fri Feb  6 18:34:34 2009
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 06 Feb 2009 17:34:34 +0000
Subject: [OpenSIPS-Devel] [ opensips-Bugs-2573029 ] [trunk/r5254] crash in
	dialog/
Message-ID: <E1LVUb4-0003hz-SG@g45xhf1.ch3.sourceforge.com>

Bugs item #2573029, was opened at 2009-02-06 17:40
Message generated for change (Settings changed) made by bogdan_iancu
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=2573029&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: Accepted
>Priority: 9
Private: No
Submitted By: Nobody/Anonymous (nobody)
>Assigned to: Bogdan-Andrei Iancu (bogdan_iancu)
Summary: [trunk/r5254] crash in dialog/

Initial Comment:
(from vasil.kolev at attractel.com)

Turns out that you can pass rpl == FAKED_REPLY (which is -1) to dlg_onreply(), which will in turn try to dereference it and crash. This fixes it for me, if you're interested, I can reproduce the core dump.

This happens when testing presence and related stuff.


--- modules/dialog/dlg_handlers.c	(revision 5254)
+++ modules/dialog/dlg_handlers.c	(working copy)
@@ -288,24 +288,29 @@
 		LM_DBG("dialog %p confirmed\n",dlg);
 
 		/* get to tag*/
-		if ( !rpl->to && ((parse_headers(rpl, HDR_TO_F,0)<0) || !rpl->to) ) {
-			LM_ERR("bad reply or missing TO hdr :-/\n");
-			tag.s = 0;
-			tag.len = 0;
-		} else {
-			tag = get_to(rpl)->tag_value;
-			if (tag.s==0 || tag.len==0) {
-				LM_ERR("missing TAG param in TO hdr :-/\n");
+		if ( rpl != FAKED_REPLY){
+			if ( !rpl->to && ((parse_headers(rpl, HDR_TO_F,0)<0) || !rpl->to) ) {
+				LM_ERR("bad reply or missing TO hdr :-/\n");
 				tag.s = 0;
 				tag.len = 0;
+			} else {
+				tag = get_to(rpl)->tag_value;
+				if (tag.s==0 || tag.len==0) {
+					LM_ERR("missing TAG param in TO hdr :-/\n");
+					tag.s = 0;
+					tag.len = 0;
+				}
 			}
+			/* save callee's tag, cseq, contact and record route*/
+			if (populate_leg_info( dlg, rpl, t, DLG_CALLEE_LEG, &tag) !=0) {
+				LM_ERR("could not add further info to the dialog\n");
+			}
+		} else {
+			LM_DBG("FAKED_REPLY detected\n");
+			tag.s = 0;
+			tag.len = 0;
 		}
 
-		/* save callee's tag, cseq, contact and record route*/
-		if (populate_leg_info( dlg, rpl, t, DLG_CALLEE_LEG, &tag) !=0) {
-			LM_ERR("could not add further info to the dialog\n");
-		}
-
 		/* set start time */
 		dlg->start_ts = (unsigned int)(time(0));
 


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

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


From noreply at sourceforge.net  Fri Feb  6 19:14:33 2009
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 06 Feb 2009 18:14:33 +0000
Subject: [OpenSIPS-Devel] [ opensips-Bugs-2538399 ] Bug in presence when
	using fallback2db
Message-ID: <E1LVVDl-0001td-Uo@h45xhf1.ch3.sourceforge.com>

Bugs item #2538399, was opened at 2009-01-26 21:39
Message generated for change (Comment added) made by anca_vamanu
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=2538399&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: Oren K (oren_k)
Assigned to: Anca Vamanu (anca_vamanu)
Summary: Bug in presence when using fallback2db

Initial Comment:
Hi,

While using the presence module, I run this scenario:

a. user1 SUBSCRIBE's to presence of user2
(subscription is now pending)

b. user2 allows user1 in pres-rules
(refreshWatchers is called, subscription is now active. user1 receives a NOTIFY from presence server with user2's current tuple and Subscription-State: active)

c. user2 PUBLISH'es a new presence tuple
-- at this point presence server should NOTIFY user1 of the new presence but it doesn't (that's the bug).


My modparams:

modparam("presence|presence_xml", "db_url", "mysql://root at localhost/opensips")

modparam("presence", "server_address", "sip:presence.example.com:10500")

modparam("presence", "fallback2db", 1)
modparam("presence", "clean_period", 30)


What I see in the debug trace is that get_subs_dialog (from notify.c) can't find any dialogs in the database, and all those in the subs hash are flagged NO_UPDATEDB_FLAG. This is probably what's causing the problem. 
Strangely, in the above scenario if user1 un-SUBSCRIBEs and re-SUBSCRIBEs to user2's presence - it does receive notifications.

Regards,
Oren K.

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

>Comment By: Anca Vamanu (anca_vamanu)
Date: 2009-02-06 20:14

Message:
Hi Oren,

I have just downloaded myself the release and tested and the scenario that
you described works. 
Do you notice any error in your log file?

regards,
Anca

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

Comment By: Oren K (oren_k)
Date: 2009-02-01 18:41

Message:
Sorry I forgot to login, that comment is from me :)

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

Comment By: Nobody/Anonymous (nobody)
Date: 2009-01-28 17:12

Message:
Thanks for the reply anca. Version is opensips-1.4.4-tls, compiled from the
sources with TLS="1". 

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

Comment By: Anca Vamanu (anca_vamanu)
Date: 2009-01-28 13:48

Message:
Hi Oren,

What OpenSIPS version are you using? Trunk or stable release?

regards,
Anca

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

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


From noreply at sourceforge.net  Fri Feb  6 19:18:04 2009
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 06 Feb 2009 18:18:04 +0000
Subject: [OpenSIPS-Devel] [ opensips-Bugs-2430807 ] Opensips crashes when
	publish received for RLS list
Message-ID: <E1LVVHA-00028T-3j@h45xhf1.ch3.sourceforge.com>

Bugs item #2430807, was opened at 2008-12-15 13:04
Message generated for change (Comment added) made by anca_vamanu
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=2430807&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: 8
Private: No
Submitted By: Nathan (rmnathan)
Assigned to: Anca Vamanu (anca_vamanu)
Summary: Opensips crashes when publish received for RLS list

Initial Comment:
Version - trunk(5049)
I have tried all sort of following thing to generate core . But it failed to generate core dump.
1.  disable_core_dump is set to no
2. set fork=no and child=no
3. tried to find core dump  at /
4. compiled opensips with the following command
    make mode=debug modules
    echo $?
    make mode=debug prefix=/usr/local/ install
5. OS stinbng46:/# uname -a
Linux stinbng46 2.6.18-staros-v2-20294-deb #1 SMP Mon Jul 14 05:18:18 EDT 2008 i686 GNU/Linux ( With same OS openser created core dump)

Is there any anything I might be missing? please help me to generate core dump , it will be very helpful for debugging.

Crash:
=====
Crash observed when notify sent out for RLS list in case of PUBLISH received. for more information please find the attached logs.

Dec 15 05:12:44 [15278] DBG:core:parse_uri:  uri params:
   transport=<>, val=<>, proto=0
Dec 15 05:12:44 [15278] DBG:core:parse_uri:    user-param=<>, val=<>
Dec 15 05:12:44 [15278] DBG:core:parse_uri:    method=<>, val=<>
Dec 15 05:12:44 [15278] DBG:core:parse_uri:    ttl=<>, val=<>
Dec 15 05:12:44 [15278] DBG:core:parse_uri:    maddr=<>, val=<>
Dec 15 05:12:44 [15278] DBG:core:parse_uri:    lr=<lr>
Dec 15 05:12:44 [15278] DBG:core:mk_proxy: doing DNS lookup...
Dec 15 05:12:44 [15278] DBG:tm:dlg2hash: 21643
Dec 15 05:12:44 [15278] DBG:tm:print_request_uri: sip:c3-1 at 192.168.126.151:40000
Dec 15 05:12:44 [15278] DBG:tm:set_timer: relative timeout is 500000
Dec 15 05:12:44 [15278] DBG:tm:insert_timer_unsafe: [4]: 0xb5be4a64 (20500000)
Dec 15 05:12:44 [15278] DBG:tm:set_timer: relative timeout is 30
Dec 15 05:12:44 [15278] DBG:tm:insert_timer_unsafe: [0]: 0xb5be4a84 (50)
Dec 15 05:12:44 [15278] DBG:rls:timer_send_notify: Found rl-subs record in hash table
Dec 15 05:12:44 [15277] INFO:core:handle_sigs: child process 15278 exited by a signal 11
Dec 15 05:12:44 [15277] INFO:core:handle_sigs: core was not generated
Dec 15 05:12:44 [15277] INFO:core:handle_sigs: terminating due to SIGCHLD
Dec 15 05:12:44 [15279] INFO:core:sig_usr: signal 15 received

Dec 15 05:12:44 [15277] DBG:core:shm_mem_destroy:
Dec 15 05:12:44 [15277] DBG:core:shm_mem_destroy: destroying the shared memory lock
Dec 15 05:12:44 [15277] DBG:core:handle_sigs: terminating due to SIGCHLD

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

>Comment By: Anca Vamanu (anca_vamanu)
Date: 2009-02-06 20:17

Message:
Hi rmnathan,

As I have asked in a previous post, please try to catch the Notify that
generates this error so I can investigate.

regards,
Anca

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

Comment By: Nathan (rmnathan)
Date: 2009-02-02 11:04

Message:
Hi Anca,
I have tested with new clone . The crash is not observed. but i have seen
lot of error message like beow. I will update log and call flow for this
error message in the respective bug item.

Feb  2 14:26:28 [26461] ERROR:rls:parse_subs_state: terminated state and
no reason foundFeb  2 14:26:28 [26461] ERROR:rls:rls_handle_notify: while
parsing 'Subscription-State' header
Feb  2 14:26:28 [26461] ERROR:rls:parse_subs_state: terminated state and
no reason foundFeb  2 14:26:28 [26461] ERROR:rls:rls_handle_notify: while
parsing 'Subscription-State' header
Feb  2 14:26:29 [26461] ERROR:rls:rls_notify_callback: record not found in
hash table
Feb  2 14:26:34 [26461] ERROR:rls:parse_subs_state: terminated state and
no reason foundFeb  2 14:26:34 [26461] ERROR:rls:rls_handle_notify: while
parsing 'Subscription-State' header
Feb  2 14:26:34 [26461] ERROR:rls:parse_subs_state: terminated state and
no reason foundFeb  2 14:26:34 [26461] ERROR:rls:rls_handle_notify: while
parsing 'Subscription-State' header

Thanks lot

Regards,
rmnathan

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

Comment By: Anca Vamanu (anca_vamanu)
Date: 2009-01-23 15:16

Message:
Hi Rmnathan,

Yesterday I have found a double free bug in rls module. Can you please
update your version and test again?

Thanks and regards,
Anca

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

Comment By: Nathan (rmnathan)
Date: 2009-01-22 08:53

Message:
Hi Anca,
Any update on this issue?

Regards,
rmnathan

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

Comment By: Nobody/Anonymous (nobody)
Date: 2009-01-12 15:55

Message:
Hi Anca,
The details of error message and call scenario as follows

1.Error Message
=================
 Only following error message is getting at the time of crashing
Jan 12 08:20:10 [27860] WARNING:core:main: no fork mode
Jan 12 08:21:10 [27860] ERROR:core:db_do_insert: invalid parameter value
Jan 12 08:21:10 [27860] ERROR:pua:db_update: while inserting in db table
pua

2. Setup details
=================
UE 1 
	-------	   PROXY  --------- Opensips
UE 2 

Note : All users are in same domain

UE 2 will have following list in openxcap table
----------------------------------------------------
It has 100 list  for each user

 uE2_1, UE2_2, UE2_3 ..
UE2_1 list will have 5 entry uri like UE1_1,UE1_2,UE1_3,UE1_4,UE1_5
UE2_2 list will have 5 entry uri like UE1_2,UE1_3,UE1_4,UE1_5,UE1_6
simillary it will go for 100 user
.
.
UE2_100 list will have 5 entry uri like UE1_100,UE1_1,UE1_2,UE1_3,UE1_4

UE 1 will have following list in openxcap table
----------------------------------------------------
It has 100 list  for each user

 uE2_1, UE2_2, UE2_3 ..
UE1_1 list will have 5 entry uri like UE2_1,UE2_2,UE2_3,UE2_4,UE2_5
UE1_2 list will have 5 entry uri like UE2_2,UE2_3,UE2_4,UE2_5,UE2_6
simillary it will go for 100 user
.
.

UE1_100 list will have 5 entry uri like UE2_100,UE2_1,UE2_2,UE2_3,UE2_4


Sample Message flow for UE1 for one user 
========================================

1. UE 1(UE1_1) will send subscribe message to rls list UE1_1 
2. UE 1 will send publish 

simillary UE2_1 .. will send subscribe and publish.


Regards,
rmnathan

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

Comment By: Anca Vamanu (anca_vamanu)
Date: 2009-01-08 18:06

Message:
Hi,

I did not succeeded to get segmentation fault on my machine or to detect
the problem in the code and from your trace. Can you please tell me if see
any errors in you log file? And what scenario are you using when testing?

regards,
Anca



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

Comment By: Nathan (rmnathan)
Date: 2009-01-07 14:52

Message:
crash 2 with full bt trace
===================
error message before crashing:
Jan  7 07:21:05 [10134] ERROR:core:db_do_insert: invalid parameter value
Jan  7 07:21:05 [10134] ERROR:pua:db_update: while inserting in db table
pua

Core was generated by `/usr/local/sbin/opensips -m 1024'.
Program terminated with signal 11, Segmentation fault.
#0  fm_malloc (qm=0x81a3ba0, size=1528) at mem/f_malloc.c:267
267                             if ((*f)->size>=size) goto found;
(gdb) bt full
#0  fm_malloc (qm=0x81a3ba0, size=1528) at mem/f_malloc.c:267
        f = (struct fm_frag **) 0x81a4330
        hash = 239
#1  0xb78f1b51 in agg_body_sendn_update (rl_uri=0x81b31b0,
boundary_string={s = 0x81b1970 "gQIIPDYu2UDVZoZv5NTp3DgT", len = 24},
rlmi_body=0xbf9ad484,
    multipart_body=0xbf9ad47c, subs=0x81b31b0, hash_code=1381) at
notify.c:238
        cid = {s = 0x81b1c50 "1231330858.sip:c5-1 at 10.6.2.246.1189641421",
len = 41}
        len = 1526
        body = {s = 0x0, len = 0}
        __FUNCTION__ = "agg_body_sendn_update"
#2  0xb78f4efe in timer_send_notify (ticks=180, param=0x0) at
resource_notify.c:544
        query_cols = {0xb7906844, 0xb7ab9510}
        update_cols = {0xb7906844}
        result_cols = {0xb7906834, 0xb790683c, 0xb790684c, 0xb790685c,
0xb7906854, 0xb7906864, 0x0}
        query_vals = {{type = DB_INT, nul = 0, free = 2007220120, val =
{int_val = 1, double_val = 1.6975966328216244e-313, time_val = 1,
      string_val = 0x1 <Address 0x1 out of bounds>, str_val = {s = 0x1
<Address 0x1 out of bounds>, len = 8}, blob_val = {
        s = 0x1 <Address 0x1 out of bounds>, len = 8}, bitmap_val = 1}},
{type = 135996560, nul = 0, free = -1080372044, val = {int_val = 135974160,
      double_val = 6.7180161178120992e-316, time_val = 135974160,
string_val = 0x81acd10 "?\225??", str_val = {s = 0x81acd10 "?\225??",
len = 0},
      blob_val = {s = 0x81acd10 "?\225??", len = 0}, bitmap_val =
135974160}}}
        update_vals = {{type = DB_DATETIME, nul = 2007220120, free =
-1213492080, val = {int_val = -1, double_val = -1.5830897899132156e-40,
time_val = -1,
      string_val = 0xffffffff <Address 0xffffffff out of bounds>, str_val
= {s = 0xffffffff <Address 0xffffffff out of bounds>, len = -1213492016},
      blob_val = {s = 0xffffffff <Address 0xffffffff out of bounds>, len =
-1213492016}, bitmap_val = 4294967295}}}
        i = 5
        result = (db_res_t *) 0x81b1768
        prev_did = 0x481c5c3c
"c5-1-80;227413568;97b57f2144c425bc44f2e7a21eb22549-57d9"
        curr_did = 0x481c601c
"c6-1-80;227413312;97b57f2144c425bc44f2e7a21eb22549-4c39"
        row_vals = (db_val_t *) 0x81b2d78
        resource_uri = 0x481c6054 "sip:s6-1 at 10.6.2.246"
        pres_state = 0x481c6080 "<?xml version=\"1.0\"
encoding=\"UTF-8\"?>\n<presence xmlns=\"urn:ietf:params:xml:ns:pidf\"
xmlns:rpid=\"urn:ietf:params:xml:ns:pidf:rpid\"
xmlns:dm=\"urn:ietf:params:xml:ns:pidf:data-model\"
xmlns:pcp=\"urn:ietf"...
        callid = {s = 0x481c5c3c
"c5-1-80;227413568;97b57f2144c425bc44f2e7a21eb22549-57d9", len = 7}
        to_tag = {s = 0x481c5c4e "97b57f2144c425bc44f2e7a21eb22549-57d9",
len = 37}
        from_tag = {s = 0x481c5c44
"227413568;97b57f2144c425bc44f2e7a21eb22549-57d9", len = 9}
        rlmi_doc = (xmlDocPtr) 0x481af758
        list_node = (xmlNodePtr) 0x481accb8
        instance_node = (xmlNodePtr) 0x481af9a0
        resource_node = (xmlNodePtr) 0x481af8b0
        hash_code = 1381
        size = 2048
        buf_len = 1004
        buf = 0x81b3380
"--gQIIPDYu2UDVZoZv5NTp3DgT\r\n\r\nContent-Transfer-Encoding:
binary\r\nContent-ID:
<1231330858.sip:s5-1 at 10.6.2.246.596516649>\r\nContent-Type:
application/pidf+xml\r\n\r\n<?xml version=\"1.0\"
encoding=\"UTF-8\"?>\n<p"...
        auth_state = <value optimized out>
        contor = 1
        auth_state_flag = 2
        bstr = {s = 0x81b1970 "gQIIPDYu2UDVZoZv5NTp3DgT", len = 24}
        rlmi_cont = {
  s = 0x481aed98 "<?xml version=\"1.0\"?>\n<list
uri=\"sip:c5-1 at 10.6.2.246\" xmlns=\"urn:ietf:params:xml:ns:rlmi\"
version=\"5\" fullState=\"false\">\n  <resource
uri=\"sip:s5-1 at 10.6.2.246\">\n    <instance id=\"icDW4oK5\"
state=\"activ"..., len = 274}
        multi_cont = {
  s = 0x81b3380
"--gQIIPDYu2UDVZoZv5NTp3DgT\r\n\r\nContent-Transfer-Encoding:
binary\r\nContent-ID:
<1231330858.sip:s5-1 at 10.6.2.246.596516649>\r\nContent-Type:
application/pidf+xml\r\n\r\n<?xml version=\"1.0\"
encoding=\"UTF-8\"?>\n<p"..., len = 1004}
        s = (subs_t *) 0x77af7598
        dialog = (subs_t *) 0x81b31b0
        rl_uri = 0x81b2a80 "sip:c5-1 at 10.6.2.246"
        str_aux = <value optimized out>
        __FUNCTION__ = "timer_send_notify"
#3  0x080ccfb5 in start_timer_processes () at timer.c:280
---Type <return> to continue, or q <return> to quit---
        tpl = (struct sr_timer_process *) 0x81acad8
        pid = <value optimized out>
        first = <value optimized out>
        __FUNCTION__ = "start_timer_processes"
#4  0x0806f189 in main (argc=3, argv=0xbf9ad664) at main.c:666
        cfg_log_stderr = 0
        cfg_stream = (FILE *) 0x481a4008
        c = <value optimized out>
        r = <value optimized out>
        tmp = 0xbf9aedec ""
        tmp_len = <value optimized out>
        port = <value optimized out>
        proto = <value optimized out>
        ret = <value optimized out>
        seed = 4221279407
        rfd = 4
        __FUNCTION__ = "main"
(gdb)

crash 3 with full bt trace
===================
error message before crashing:
Jan  7 07:29:00 [10190] ERROR:db_mysql:db_mysql_str2val: invalid parameter
value
Jan  7 07:29:00 [10190] ERROR:db_mysql:db_mysql_convert_row: failed to
convert value
Jan  7 07:29:09 [10189] ERROR:core:db_do_insert: invalid parameter value
Jan  7 07:29:09 [10189] ERROR:pua:db_update: while inserting in db table
pua

Core was generated by `/usr/local/sbin/opensips -m 1024'.
Program terminated with signal 11, Segmentation fault.
#0  db_free_row (_r=0x81b79e8) at db/db_row.c:62
62                      switch (VAL_TYPE(_val)) {
(gdb) bt full
#0  db_free_row (_r=0x81b79e8) at db/db_row.c:62
        col = 0
        _val = (db_val_t *) 0x0
        __FUNCTION__ = "db_free_row"
#1  0xb7d9b580 in db_mysql_convert_row (_h=0x81b3820, _res=0x81ad938,
_r=0x81b79e8) at row.c:69
        lengths = (long unsigned int *) 0x481aebcc
        i = 135935876
        __FUNCTION__ = "db_mysql_convert_row"
#2  0xb7d9aeca in db_mysql_convert_result (_h=0x81b3820, _r=0x81ad938) at
res.c:171
        __FUNCTION__ = "db_mysql_convert_result"
#3  0xb7d98a2f in db_mysql_store_result (_h=0x81b3820, _r=0xbf9f4500) at
dbase.c:177
        __FUNCTION__ = "db_mysql_store_result"
#4  0x0811b94f in db_do_query (_h=0x81b3820, _k=0xbf9f44f4, _op=0x0,
_v=0xbf9f4474, _c=0xbf9f449c, _n=1, _nc=6, _o=0xb78e6834, _r=0xbf9f4500,
    val2str=0xb7d9b780 <db_mysql_val2str>, submit_query=0xb7d98de9
<db_mysql_submit_query>, store_result=0xb7d989c7 <db_mysql_store_result>)
    at db/db_query.c:105
        tmp = <value optimized out>
        off = 132
        ret = <value optimized out>
        __FUNCTION__ = "db_do_query"
#5  0xb7d97d05 in db_mysql_query (_h=0x81b3820, _k=0xbf9f44f4, _op=0x0,
_v=0xbf9f4474, _c=0xbf9f449c, _n=1, _nc=6, _o=0xb78e6834, _r=0xbf9f4500)
    at dbase.c:247
No locals.
#6  0xb78d4c75 in timer_send_notify (ticks=80, param=0x0) at
resource_notify.c:493
        query_cols = {0xb78e6844, 0x0}
        update_cols = {0xb78e6844}
        result_cols = {0xb78e6834, 0xb78e683c, 0xb78e684c, 0xb78e685c,
0xb78e6854, 0xb78e6864, 0x0}
        query_vals = {{type = DB_INT, nul = 0, free = 2007089048, val =
{int_val = 1, double_val = -2.766852607421637e-39, time_val = 1,
      string_val = 0x1 <Address 0x1 out of bounds>, str_val = {s = 0x1
<Address 0x1 out of bounds>, len = -1209130788}, blob_val = {
        s = 0x1 <Address 0x1 out of bounds>, len = -1209130788},
bitmap_val = 1}}, {type = 3085836512, nul = -1209131020, free = 310, val =
{int_val = 310,
      double_val = -0.03053575754165757, time_val = 310, string_val =
0x136 <Address 0x136 out of bounds>, str_val = {
        s = 0x136 <Address 0x136 out of bounds>, len = -1080081212},
blob_val = {s = 0x136 <Address 0x136 out of bounds>, len = -1080081212},
      bitmap_val = 310}}}
        update_vals = {{type = DB_DATETIME, nul = 2007089048, free =
-1080081152, val = {int_val = -1, double_val = -3.3348689399357007e-39,
time_val = -1,
      string_val = 0xffffffff <Address 0xffffffff out of bounds>, str_val
= {s = 0xffffffff <Address 0xffffffff out of bounds>, len = -1208866784},
      blob_val = {s = 0xffffffff <Address 0xffffffff out of bounds>, len =
-1208866784}, bitmap_val = 4294967295}}}
        i = <value optimized out>
        result = (db_res_t *) 0x81ad938
        prev_did = <value optimized out>
        curr_did = <value optimized out>
        row_vals = <value optimized out>
        resource_uri = <value optimized out>
        pres_state = <value optimized out>
        callid = {s = 0x0, len = 0}
        to_tag = {s = 0x481c67ed
"h\034H_h\034H`h\034H?k\034Hc3-2-80;210632768;97b57f2144c425bc44f2e7a21eb22549-f3e9",
len = 79}
        from_tag = {s = 0x481c67e4
"4h\034HHh\034HJh\034H_h\034H`h\034H?k\034Hc3-2-80;210632768;97b57f2144c425bc44f2e7a21eb22549-f3e9",
len = 8}
        rlmi_doc = <value optimized out>
        list_node = <value optimized out>
        instance_node = <value optimized out>
        resource_node = <value optimized out>
        hash_code = <value optimized out>
        size = <value optimized out>
        buf_len = <value optimized out>
        buf = <value optimized out>
        auth_state = <value optimized out>
        contor = <value optimized out>
        auth_state_flag = <value optimized out>
        bstr = {s = 0x0, len = 0}
---Type <return> to continue, or q <return> to quit---
        rlmi_cont = {s = 0x0, len = 0}
        multi_cont = {s = 0x0, len = 8}
        s = <value optimized out>
        dialog = <value optimized out>
        rl_uri = <value optimized out>
        str_aux = <value optimized out>
        __FUNCTION__ = "timer_send_notify"
#7  0x080ccfb5 in start_timer_processes () at timer.c:280
        tpl = (struct sr_timer_process *) 0x81acad8
        pid = <value optimized out>
        first = <value optimized out>
        __FUNCTION__ = "start_timer_processes"
#8  0x0806f189 in main (argc=3, argv=0xbf9f46b4) at main.c:666
        cfg_log_stderr = 0
        cfg_stream = (FILE *) 0x481a4008
        c = <value optimized out>
        r = <value optimized out>
        tmp = 0xbf9f5dec ""
        tmp_len = <value optimized out>
        port = <value optimized out>
        proto = <value optimized out>
        ret = <value optimized out>
        seed = 3089561270
        rfd = 4
        __FUNCTION__ = "main"
(gdb)



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

Comment By: Nathan (rmnathan)
Date: 2009-01-07 14:15

Message:
Hi
the full trace as follows 
 
Core was generated by `/usr/local/sbin/opensips'.
Program terminated with signal 11, Segmentation fault.
#0  0xb78e7eca in timer_send_notify (ticks=120, param=0x0) at
resource_notify.c:721
721                            
if(strncmp(row_vals[resource_uri_col].val.string_val,
(gdb) bt full
#0  0xb78e7eca in timer_send_notify (ticks=120, param=0x0) at
resource_notify.c:721
        query_cols = {0xb78f8844, 0xb7aab510}
        update_cols = {0x0}
        result_cols = {0xb78f8834, 0xb78f883c, 0xb78f884c, 0xb78f885c,
0xb78f8854, 0xb78f8864, 0x0}
        query_vals = {{type = DB_INT, nul = 0, free = -1247617128, val =
{int_val = 1, double_val = 4.2439915824246103e-314, time_val = 1,
      string_val = 0x1 <Address 0x1 out of bounds>, str_val = {s = 0x1
<Address 0x1 out of bounds>, len = 2}, blob_val = {
        s = 0x1 <Address 0x1 out of bounds>, len = 2}, bitmap_val = 1}},
{type = DB_DOUBLE, nul = 0, free = -1081894044, val = {int_val = 135974160,
      double_val = 6.7180161178120992e-316, time_val = 135974160,
string_val = 0x81acd10 "??????\032\b", str_val = {s = 0x81acd10
"??????\032\b", len = 0},
      blob_val = {s = 0x81acd10 "??????\032\b", len = 0}, bitmap_val
= 135974160}}}
        update_vals = {{type = DB_DATETIME, nul = -1247617128, free =
-1243838944, val = {int_val = -1213549416, double_val =
-1.5328670054899573e-40,
      time_val = -1213549416, string_val = 0xb7aab498 "?S??\006",
str_val = {s = 0xb7aab498 "?S??\006", len = -1213549360}, blob_val = {
        s = 0xb7aab498 "?S??\006", len = -1213549360}, bitmap_val =
3081417880}}}
        i = 298
        result = (db_res_t *) 0x828f678
        prev_did = 0x4821159c
"s6-13-80;100595200;97b57f2144c425bc44f2e7a21eb22549-1265"
        curr_did = 0x48211d5c
"s6-14-80;218035712;97b57f2144c425bc44f2e7a21eb22549-365a"
        row_vals = (db_val_t *) 0x64697072
        resource_uri = <value optimized out>
        pres_state = 0x48211dc2 "<?xml version=\"1.0\"
encoding=\"UTF-8\"?>\n<presence xmlns=\"urn:ietf:params:xml:ns:pidf\"
xmlns:rpid=\"urn:ietf:params:xml:ns:pidf:rpid\"
xmlns:dm=\"urn:ietf:params:xml:ns:pidf:data-model\"
xmlns:pcp=\"urn:ietf"...
        callid = {s = 0x48211d5c
"s6-14-80;218035712;97b57f2144c425bc44f2e7a21eb22549-365a", len = 8}
        to_tag = {s = 0x48211d6f "97b57f2144c425bc44f2e7a21eb22549-365a",
len = 37}
        from_tag = {s = 0x48211d65
"218035712;97b57f2144c425bc44f2e7a21eb22549-365a", len = 9}
        rlmi_doc = (xmlDocPtr) 0x481aec20
        list_node = (xmlNodePtr) 0x481accb8
        instance_node = (xmlNodePtr) 0x481f0da0
        resource_node = (xmlNodePtr) 0x481af8c0
        hash_code = 349
        size = 6144
        buf_len = 1007
        buf = 0x8298040
"--uiJUnfDUyfcSFWRINqnYyVEx\r\n\r\nContent-Transfer-Encoding:
binary\r\nContent-ID:
<1231322726.sip:c6-18 at 10.6.2.246.596516649>\r\nContent-Type:
application/pidf+xml\r\n\r\n<?xml version=\"1.0\"
encoding=\"UTF-8\"?>\n<"...
        auth_state = <value optimized out>
        contor = 1
        auth_state_flag = <value optimized out>
        bstr = {s = 0x8292c30 "uiJUnfDUyfcSFWRINqnYyVEx", len = 24}
        rlmi_cont = {
  s = 0x481f0fd8 "pT??pT???\017\037H?\017\037H.0\"?>\n<list
uri=\"sip:s6-13 at 10.6.2.246\" xmlns=\"urn:ietf:params:xml:ns:rlmi\"
version=\"2\" fullState=\"false\">\n  <resource
uri=\"sip:c6-17 at 10.6.2.246\">\n    <instance id=\"icDW4oK5\"
state=\"act"..., len = 959}
        multi_cont = {
  s = 0x8298040
"--uiJUnfDUyfcSFWRINqnYyVEx\r\n\r\nContent-Transfer-Encoding:
binary\r\nContent-ID:
<1231322726.sip:c6-18 at 10.6.2.246.596516649>\r\nContent-Type:
application/pidf+xml\r\n\r\n<?xml version=\"1.0\"
encoding=\"UTF-8\"?>\n<"..., len = 6053}
        s = (subs_t *) 0xb602c300
        dialog = (subs_t *) 0x81a7ef0
        rl_uri = 0x8291670 "sip:s6-14 at 10.6.2.246"
        str_aux = <value optimized out>
        __FUNCTION__ = "timer_send_notify"
#1  0x080ccfb5 in start_timer_processes () at timer.c:280
        tpl = (struct sr_timer_process *) 0x81acad8
        pid = <value optimized out>
        first = <value optimized out>
        __FUNCTION__ = "start_timer_processes"
#2  0x0806f189 in main (argc=1, argv=0xbf839d14) at main.c:666
        cfg_log_stderr = 0
        cfg_stream = (FILE *) 0x481a4008
        c = <value optimized out>
        r = <value optimized out>
---Type <return> to continue, or q <return> to quit---
        tmp = 0x8166200 "\034a\026\bhF??@???"
        tmp_len = <value optimized out>
        port = <value optimized out>
        proto = <value optimized out>
        ret = <value optimized out>
        seed = 82752229
        rfd = 4
        __FUNCTION__ = "main"
(gdb)

Regards,
rmnathan

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

Comment By: Nobody/Anonymous (nobody)
Date: 2009-01-07 13:04

Message:
It would help to provide the backtrace with the full context and the value
of the local variables. To do that use "bt full" instead of just "bt".

Dan


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

Comment By: Nathan (rmnathan)
Date: 2009-01-07 12:40

Message:
Hi Anca,
I observed few crashes as follows while testing with new trunck build.

Crash 1:
======
Core was generated by `/usr/local/sbin/opensips -m 1024'.
Program terminated with signal 11, Segmentation fault.
#0  0xb7e18d00 in strncmp () from /lib/libc.so.6
(gdb) bt
#0  0xb7e18d00 in strncmp () from /lib/libc.so.6
#1  0xb78cfee3 in timer_send_notify (ticks=40, param=0x0) at
resource_notify.c:721
#2  0x080ccfb5 in start_timer_processes () at timer.c:280
#3  0x0806f189 in main (argc=3, argv=0xbfb57014) at main.c:666

Crash 2:
======
Program terminated with signal 11, Segmentation fault.
#0  fm_malloc (qm=0x81a3ba0, size=2640) at mem/f_malloc.c:267
267                             if ((*f)->size>=size) goto found;
(gdb) bt
#0  fm_malloc (qm=0x81a3ba0, size=2640) at mem/f_malloc.c:267
#1  0xb78dcb51 in agg_body_sendn_update (rl_uri=0x81a7ef0,
boundary_string={s = 0x81dadc0 "j5dDEBAL5H1LAtor2qUGI2ac", len = 24},
rlmi_body=0xbfef61d4,
    multipart_body=0xbfef61cc, subs=0x81a7ef0, hash_code=1978) at
notify.c:238
#2  0xb78dfefe in timer_send_notify (ticks=60, param=0x0) at
resource_notify.c:544
#3  0x080ccfb5 in start_timer_processes () at timer.c:280
#4  0x0806f189 in main (argc=3, argv=0xbfef63b4) at main.c:666

crash 3:
======
#0  0xb78e7eca in timer_send_notify (ticks=120, param=0x0) at
resource_notify.c:721
721                            
if(strncmp(row_vals[resource_uri_col].val.string_val,
(gdb) bt
#0  0xb78e7eca in timer_send_notify (ticks=120, param=0x0) at
resource_notify.c:721
#1  0x080ccfb5 in start_timer_processes () at timer.c:280
#2  0x0806f189 in main (argc=1, argv=0xbf839d14) at main.c:666

crash 4:
======
Core was generated by `/usr/local/sbin/opensips -m 1024'.
Program terminated with signal 11, Segmentation fault.
#0  db_free_row (_r=0x81c25d0) at db/db_row.c:62
62                      switch (VAL_TYPE(_val)) {

crash 5:
======
Core was generated by `/usr/local/sbin/opensips'.
Program terminated with signal 11, Segmentation fault.
#0  0x080f9282 in parse_uri (buf=0x8 <Address 0x8 out of bounds>,
len=135995841, uri=0xbf9fbfe0) at parser/parse_uri.c:329
329             scheme=buf[0]+(buf[1]<<8)+(buf[2]<<16)+(buf[3]<<24);


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

Comment By: Anca Vamanu (anca_vamanu)
Date: 2009-01-06 16:41

Message:
Hi Meganathan,

I think that I have finally found the bug this time. Can you please
update, test again and confirm?

Thanks and regards,
Anca

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

Comment By: Nathan (rmnathan)
Date: 2008-12-31 11:37

Message:
Hi Anca,
 Any update on this issue?

Regards,
Meganathan.

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

Comment By: Nathan (rmnathan)
Date: 2008-12-18 16:45

Message:
Hi Anca 
 I have retested with latest build (rev 5071). Again I got the crash  

(gdb) bt
#0  0xb7e1861d in _IO_str_overflow () from /lib/libc.so.6
#1  0xb7e17747 in _IO_default_xsputn () from /lib/libc.so.6
#2  0xb7deea94 in vfprintf () from /lib/libc.so.6
#3  0xb7e0c92c in vsprintf () from /lib/libc.so.6
#4  0xb7df775e in sprintf () from /lib/libc.so.6
#5  0xb78d810b in timer_send_notify (ticks=40, param=0x0) at
resource_notify.c:700
#6  0x080ccb55 in start_timer_processes () at timer.c:280
#7  0x0806ef69 in main (argc=1, argv=0xbfa78f44) at main.c:666

Regards,
rmnathan


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

Comment By: Anca Vamanu (anca_vamanu)
Date: 2008-12-18 14:28

Message:
Hi rmnathan,

I have made some changes in the rls module. 
Can you please update and test again?

regards,
Anca

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

Comment By: Nathan (rmnathan)
Date: 2008-12-16 12:12

Message:
Hi Anca,
After i compiled with following commands i got core dump with line
numbers.

make
echo $?
make prefix=/usr/local/ install

Program terminated with signal 11, Segmentation fault.
#0  0xb7e5161d in _IO_str_overflow () from /lib/libc.so.6
(gdb) bt
#0  0xb7e5161d in _IO_str_overflow () from /lib/libc.so.6
#1  0xb7e50747 in _IO_default_xsputn () from /lib/libc.so.6
#2  0xb7e27a94 in vfprintf () from /lib/libc.so.6
#3  0xb7e4592c in vsprintf () from /lib/libc.so.6
#4  0xb7e3075e in sprintf () from /lib/libc.so.6
#5  0xb7911d53 in timer_send_notify (ticks=40, param=0x0) at
resource_notify.c:687
#6  0x080ccb55 in start_timer_processes () at timer.c:280
#7  0x0806ef69 in main (argc=1, argv=0xbf805cf4) at main.c:666

regards,
rmnathan


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

Comment By: Nathan (rmnathan)
Date: 2008-12-16 11:45

Message:
Hi Anca,
I have tried with latest trunk build (rev 5060), am getting the same
crash.
I have set 'ulimit -c unlimited' also but the line numbers not getting
printed.

Core was generated by `opensips'.
Program terminated with signal 11, Segmentation fault.
#0  0xb7ec161d in _IO_str_overflow () from /lib/libc.so.6
(gdb) bt
#0  0xb7ec161d in _IO_str_overflow () from /lib/libc.so.6
#1  0xb7ec0747 in _IO_default_xsputn () from /lib/libc.so.6
#2  0xb7e97a94 in vfprintf () from /lib/libc.so.6
#3  0xb7eb592c in vsprintf () from /lib/libc.so.6
#4  0xb7ea075e in sprintf () from /lib/libc.so.6
#5  0xb799a25d in timer_send_notify () from
/usr/local//lib/opensips/modules/rls.so
#6  0x080b1194 in timer_ticker ()
#7  0x080b0fc5 in run_timer_process ()
#8  0x080b12ff in start_timer_processes ()
#9  0x08065cdd in main_loop ()
#10 0x08067f53 in main ()

Regards
rmnathan

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

Comment By: Anca Vamanu (anca_vamanu)
Date: 2008-12-15 16:19

Message:
Hi rmnathan,

I have tested myself and got a crash after some time - it was due to a
recent change that I made. I have commited the fix in trunk.
However I am not really sure it is the same as you have seen, as in your
trace there isn't enough information -like line numbers. Can you please
update and test again and report if you see the crash again. 
Btw, have you run: 'ulimit -c unlimited'?

regards,
Anca 


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

Comment By: Nathan (rmnathan)
Date: 2008-12-15 13:17

Message:
Finally core has created. Please see below

stinbng46:/# gdb /usr/local/sbin/opensips core
GNU gdb 6.4.90-debian
Copyright (C) 2006 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you
are
welcome to change it and/or distribute copies of it under certain
conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for
details.
This GDB was configured as "i486-linux-gnu"...Using host libthread_db
library "/lib/libthread_db.so.1".


warning: Can't read pathname for load map: Input/output error.
Reading symbols from /lib/libdl.so.2...done.
Loaded symbols for /lib/libdl.so.2
Reading symbols from /lib/libresolv.so.2...done.
Loaded symbols for /lib/libresolv.so.2
Reading symbols from /lib/libc.so.6...done.
Loaded symbols for /lib/libc.so.6
Reading symbols from /lib/ld-linux.so.2...done.
Loaded symbols for /lib/ld-linux.so.2
Reading symbols from /usr/local/lib/opensips/modules/db_mysql.so...done.
Loaded symbols for /usr/local//lib/opensips/modules/db_mysql.so
Reading symbols from /usr/lib/libmysqlclient.so.15...done.
Loaded symbols for /usr/lib/libmysqlclient.so.15
Reading symbols from /lib/libpthread.so.0...done.
Loaded symbols for /lib/libpthread.so.0
Reading symbols from /lib/libcrypt.so.1...done.
Loaded symbols for /lib/libcrypt.so.1
Reading symbols from /lib/libnsl.so.1...done.
Loaded symbols for /lib/libnsl.so.1
Reading symbols from /lib/libm.so.6...done.
Loaded symbols for /lib/libm.so.6
Reading symbols from /usr/lib/libz.so.1...done.
Loaded symbols for /usr/lib/libz.so.1
Reading symbols from /usr/local/lib/opensips/modules/sl.so...done.
Loaded symbols for /usr/local//lib/opensips/modules/sl.so
Reading symbols from /usr/local/lib/opensips/modules/maxfwd.so...done.
Loaded symbols for /usr/local//lib/opensips/modules/maxfwd.so
Reading symbols from /usr/local/lib/opensips/modules/textops.so...done.
Loaded symbols for /usr/local//lib/opensips/modules/textops.so
Reading symbols from /usr/local/lib/opensips/modules/tm.so...done.
Loaded symbols for /usr/local//lib/opensips/modules/tm.so
Reading symbols from /usr/local/lib/opensips/modules/rr.so...done.
Loaded symbols for /usr/local//lib/opensips/modules/rr.so
Reading symbols from /usr/local/lib/opensips/modules/presence.so...done.
Loaded symbols for /usr/local//lib/opensips/modules/presence.so
Reading symbols from /usr/lib/libxml2.so.2...done.
Loaded symbols for /usr/lib/libxml2.so.2
Reading symbols from /usr/local/lib/opensips/modules/avpops.so...done.
Loaded symbols for /usr/local//lib/opensips/modules/avpops.so
Reading symbols from /usr/local/lib/opensips/modules/pua.so...done.
Loaded symbols for /usr/local//lib/opensips/modules/pua.so
Reading symbols from /usr/local/lib/opensips/modules/mi_fifo.so...done.
Loaded symbols for /usr/local//lib/opensips/modules/mi_fifo.so
Reading symbols from
/usr/local/lib/opensips/modules/presence_xml.so...done.
Loaded symbols for /usr/local//lib/opensips/modules/presence_xml.so
Reading symbols from /usr/local/lib/opensips/modules/rls.so...done.
Loaded symbols for /usr/local//lib/opensips/modules/rls.so
Reading symbols from /usr/local/lib/opensips/modules/xlog.so...done.
Loaded symbols for /usr/local//lib/opensips/modules/xlog.so
Reading symbols from /usr/local/lib/opensips/modules/signaling.so...done.
Loaded symbols for /usr/local//lib/opensips/modules/signaling.so
Reading symbols from /lib/libnss_db.so.2...done.
Loaded symbols for /lib/libnss_db.so.2
Reading symbols from /lib/libnss_files.so.2...done.
Loaded symbols for /lib/libnss_files.so.2
Reading symbols from /usr/lib/libdb3.so.3...done.
Loaded symbols for /usr/lib/libdb3.so.3
Core was generated by `/usr/local/sbin/opensips -D'.
Program terminated with signal 11, Segmentation fault.
#0  0xb7e9f61d in _IO_str_overflow () from /lib/libc.so.6
(gdb) bt
#0  0xb7e9f61d in _IO_str_overflow () from /lib/libc.so.6
#1  0xb7e9e747 in _IO_default_xsputn () from /lib/libc.so.6
#2  0xb7e75a94 in vfprintf () from /lib/libc.so.6
#3  0xb7e9392c in vsprintf () from /lib/libc.so.6
#4  0xb7e7e75e in sprintf () from /lib/libc.so.6
#5  0xb7978256 in timer_send_notify () from
/usr/local//lib/opensips/modules/rls.so
#6  0x080b11a0 in timer_ticker ()
#7  0x080b0fd1 in run_timer_process ()
#8  0x080b130b in start_timer_processes ()
#9  0x08065cdd in main_loop ()
#10 0x08067f5f in main ()

Regards
rmnathan


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

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


From noreply at sourceforge.net  Fri Feb  6 19:21:19 2009
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 06 Feb 2009 18:21:19 +0000
Subject: [OpenSIPS-Devel] [ opensips-Bugs-2430807 ] Opensips crashes when
	publish received for RLS list
Message-ID: <E1LVVKJ-0005Bc-JW@155xhf1.ch3.sourceforge.com>

Bugs item #2430807, was opened at 2008-12-15 13:04
Message generated for change (Comment added) made by anca_vamanu
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=2430807&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: 8
Private: No
Submitted By: Nathan (rmnathan)
Assigned to: Anca Vamanu (anca_vamanu)
Summary: Opensips crashes when publish received for RLS list

Initial Comment:
Version - trunk(5049)
I have tried all sort of following thing to generate core . But it failed to generate core dump.
1.  disable_core_dump is set to no
2. set fork=no and child=no
3. tried to find core dump  at /
4. compiled opensips with the following command
    make mode=debug modules
    echo $?
    make mode=debug prefix=/usr/local/ install
5. OS stinbng46:/# uname -a
Linux stinbng46 2.6.18-staros-v2-20294-deb #1 SMP Mon Jul 14 05:18:18 EDT 2008 i686 GNU/Linux ( With same OS openser created core dump)

Is there any anything I might be missing? please help me to generate core dump , it will be very helpful for debugging.

Crash:
=====
Crash observed when notify sent out for RLS list in case of PUBLISH received. for more information please find the attached logs.

Dec 15 05:12:44 [15278] DBG:core:parse_uri:  uri params:
   transport=<>, val=<>, proto=0
Dec 15 05:12:44 [15278] DBG:core:parse_uri:    user-param=<>, val=<>
Dec 15 05:12:44 [15278] DBG:core:parse_uri:    method=<>, val=<>
Dec 15 05:12:44 [15278] DBG:core:parse_uri:    ttl=<>, val=<>
Dec 15 05:12:44 [15278] DBG:core:parse_uri:    maddr=<>, val=<>
Dec 15 05:12:44 [15278] DBG:core:parse_uri:    lr=<lr>
Dec 15 05:12:44 [15278] DBG:core:mk_proxy: doing DNS lookup...
Dec 15 05:12:44 [15278] DBG:tm:dlg2hash: 21643
Dec 15 05:12:44 [15278] DBG:tm:print_request_uri: sip:c3-1 at 192.168.126.151:40000
Dec 15 05:12:44 [15278] DBG:tm:set_timer: relative timeout is 500000
Dec 15 05:12:44 [15278] DBG:tm:insert_timer_unsafe: [4]: 0xb5be4a64 (20500000)
Dec 15 05:12:44 [15278] DBG:tm:set_timer: relative timeout is 30
Dec 15 05:12:44 [15278] DBG:tm:insert_timer_unsafe: [0]: 0xb5be4a84 (50)
Dec 15 05:12:44 [15278] DBG:rls:timer_send_notify: Found rl-subs record in hash table
Dec 15 05:12:44 [15277] INFO:core:handle_sigs: child process 15278 exited by a signal 11
Dec 15 05:12:44 [15277] INFO:core:handle_sigs: core was not generated
Dec 15 05:12:44 [15277] INFO:core:handle_sigs: terminating due to SIGCHLD
Dec 15 05:12:44 [15279] INFO:core:sig_usr: signal 15 received

Dec 15 05:12:44 [15277] DBG:core:shm_mem_destroy:
Dec 15 05:12:44 [15277] DBG:core:shm_mem_destroy: destroying the shared memory lock
Dec 15 05:12:44 [15277] DBG:core:handle_sigs: terminating due to SIGCHLD

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

>Comment By: Anca Vamanu (anca_vamanu)
Date: 2009-02-06 20:21

Message:
Sorry I did not see that you included a trace in bug #2523454 :). I will
take a look at that.

regards,
Anca

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

Comment By: Anca Vamanu (anca_vamanu)
Date: 2009-02-06 20:17

Message:
Hi rmnathan,

As I have asked in a previous post, please try to catch the Notify that
generates this error so I can investigate.

regards,
Anca

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

Comment By: Nathan (rmnathan)
Date: 2009-02-02 11:04

Message:
Hi Anca,
I have tested with new clone . The crash is not observed. but i have seen
lot of error message like beow. I will update log and call flow for this
error message in the respective bug item.

Feb  2 14:26:28 [26461] ERROR:rls:parse_subs_state: terminated state and
no reason foundFeb  2 14:26:28 [26461] ERROR:rls:rls_handle_notify: while
parsing 'Subscription-State' header
Feb  2 14:26:28 [26461] ERROR:rls:parse_subs_state: terminated state and
no reason foundFeb  2 14:26:28 [26461] ERROR:rls:rls_handle_notify: while
parsing 'Subscription-State' header
Feb  2 14:26:29 [26461] ERROR:rls:rls_notify_callback: record not found in
hash table
Feb  2 14:26:34 [26461] ERROR:rls:parse_subs_state: terminated state and
no reason foundFeb  2 14:26:34 [26461] ERROR:rls:rls_handle_notify: while
parsing 'Subscription-State' header
Feb  2 14:26:34 [26461] ERROR:rls:parse_subs_state: terminated state and
no reason foundFeb  2 14:26:34 [26461] ERROR:rls:rls_handle_notify: while
parsing 'Subscription-State' header

Thanks lot

Regards,
rmnathan

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

Comment By: Anca Vamanu (anca_vamanu)
Date: 2009-01-23 15:16

Message:
Hi Rmnathan,

Yesterday I have found a double free bug in rls module. Can you please
update your version and test again?

Thanks and regards,
Anca

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

Comment By: Nathan (rmnathan)
Date: 2009-01-22 08:53

Message:
Hi Anca,
Any update on this issue?

Regards,
rmnathan

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

Comment By: Nobody/Anonymous (nobody)
Date: 2009-01-12 15:55

Message:
Hi Anca,
The details of error message and call scenario as follows

1.Error Message
=================
 Only following error message is getting at the time of crashing
Jan 12 08:20:10 [27860] WARNING:core:main: no fork mode
Jan 12 08:21:10 [27860] ERROR:core:db_do_insert: invalid parameter value
Jan 12 08:21:10 [27860] ERROR:pua:db_update: while inserting in db table
pua

2. Setup details
=================
UE 1 
	-------	   PROXY  --------- Opensips
UE 2 

Note : All users are in same domain

UE 2 will have following list in openxcap table
----------------------------------------------------
It has 100 list  for each user

 uE2_1, UE2_2, UE2_3 ..
UE2_1 list will have 5 entry uri like UE1_1,UE1_2,UE1_3,UE1_4,UE1_5
UE2_2 list will have 5 entry uri like UE1_2,UE1_3,UE1_4,UE1_5,UE1_6
simillary it will go for 100 user
.
.
UE2_100 list will have 5 entry uri like UE1_100,UE1_1,UE1_2,UE1_3,UE1_4

UE 1 will have following list in openxcap table
----------------------------------------------------
It has 100 list  for each user

 uE2_1, UE2_2, UE2_3 ..
UE1_1 list will have 5 entry uri like UE2_1,UE2_2,UE2_3,UE2_4,UE2_5
UE1_2 list will have 5 entry uri like UE2_2,UE2_3,UE2_4,UE2_5,UE2_6
simillary it will go for 100 user
.
.

UE1_100 list will have 5 entry uri like UE2_100,UE2_1,UE2_2,UE2_3,UE2_4


Sample Message flow for UE1 for one user 
========================================

1. UE 1(UE1_1) will send subscribe message to rls list UE1_1 
2. UE 1 will send publish 

simillary UE2_1 .. will send subscribe and publish.


Regards,
rmnathan

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

Comment By: Anca Vamanu (anca_vamanu)
Date: 2009-01-08 18:06

Message:
Hi,

I did not succeeded to get segmentation fault on my machine or to detect
the problem in the code and from your trace. Can you please tell me if see
any errors in you log file? And what scenario are you using when testing?

regards,
Anca



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

Comment By: Nathan (rmnathan)
Date: 2009-01-07 14:52

Message:
crash 2 with full bt trace
===================
error message before crashing:
Jan  7 07:21:05 [10134] ERROR:core:db_do_insert: invalid parameter value
Jan  7 07:21:05 [10134] ERROR:pua:db_update: while inserting in db table
pua

Core was generated by `/usr/local/sbin/opensips -m 1024'.
Program terminated with signal 11, Segmentation fault.
#0  fm_malloc (qm=0x81a3ba0, size=1528) at mem/f_malloc.c:267
267                             if ((*f)->size>=size) goto found;
(gdb) bt full
#0  fm_malloc (qm=0x81a3ba0, size=1528) at mem/f_malloc.c:267
        f = (struct fm_frag **) 0x81a4330
        hash = 239
#1  0xb78f1b51 in agg_body_sendn_update (rl_uri=0x81b31b0,
boundary_string={s = 0x81b1970 "gQIIPDYu2UDVZoZv5NTp3DgT", len = 24},
rlmi_body=0xbf9ad484,
    multipart_body=0xbf9ad47c, subs=0x81b31b0, hash_code=1381) at
notify.c:238
        cid = {s = 0x81b1c50 "1231330858.sip:c5-1 at 10.6.2.246.1189641421",
len = 41}
        len = 1526
        body = {s = 0x0, len = 0}
        __FUNCTION__ = "agg_body_sendn_update"
#2  0xb78f4efe in timer_send_notify (ticks=180, param=0x0) at
resource_notify.c:544
        query_cols = {0xb7906844, 0xb7ab9510}
        update_cols = {0xb7906844}
        result_cols = {0xb7906834, 0xb790683c, 0xb790684c, 0xb790685c,
0xb7906854, 0xb7906864, 0x0}
        query_vals = {{type = DB_INT, nul = 0, free = 2007220120, val =
{int_val = 1, double_val = 1.6975966328216244e-313, time_val = 1,
      string_val = 0x1 <Address 0x1 out of bounds>, str_val = {s = 0x1
<Address 0x1 out of bounds>, len = 8}, blob_val = {
        s = 0x1 <Address 0x1 out of bounds>, len = 8}, bitmap_val = 1}},
{type = 135996560, nul = 0, free = -1080372044, val = {int_val = 135974160,
      double_val = 6.7180161178120992e-316, time_val = 135974160,
string_val = 0x81acd10 "?\225??", str_val = {s = 0x81acd10 "?\225??",
len = 0},
      blob_val = {s = 0x81acd10 "?\225??", len = 0}, bitmap_val =
135974160}}}
        update_vals = {{type = DB_DATETIME, nul = 2007220120, free =
-1213492080, val = {int_val = -1, double_val = -1.5830897899132156e-40,
time_val = -1,
      string_val = 0xffffffff <Address 0xffffffff out of bounds>, str_val
= {s = 0xffffffff <Address 0xffffffff out of bounds>, len = -1213492016},
      blob_val = {s = 0xffffffff <Address 0xffffffff out of bounds>, len =
-1213492016}, bitmap_val = 4294967295}}}
        i = 5
        result = (db_res_t *) 0x81b1768
        prev_did = 0x481c5c3c
"c5-1-80;227413568;97b57f2144c425bc44f2e7a21eb22549-57d9"
        curr_did = 0x481c601c
"c6-1-80;227413312;97b57f2144c425bc44f2e7a21eb22549-4c39"
        row_vals = (db_val_t *) 0x81b2d78
        resource_uri = 0x481c6054 "sip:s6-1 at 10.6.2.246"
        pres_state = 0x481c6080 "<?xml version=\"1.0\"
encoding=\"UTF-8\"?>\n<presence xmlns=\"urn:ietf:params:xml:ns:pidf\"
xmlns:rpid=\"urn:ietf:params:xml:ns:pidf:rpid\"
xmlns:dm=\"urn:ietf:params:xml:ns:pidf:data-model\"
xmlns:pcp=\"urn:ietf"...
        callid = {s = 0x481c5c3c
"c5-1-80;227413568;97b57f2144c425bc44f2e7a21eb22549-57d9", len = 7}
        to_tag = {s = 0x481c5c4e "97b57f2144c425bc44f2e7a21eb22549-57d9",
len = 37}
        from_tag = {s = 0x481c5c44
"227413568;97b57f2144c425bc44f2e7a21eb22549-57d9", len = 9}
        rlmi_doc = (xmlDocPtr) 0x481af758
        list_node = (xmlNodePtr) 0x481accb8
        instance_node = (xmlNodePtr) 0x481af9a0
        resource_node = (xmlNodePtr) 0x481af8b0
        hash_code = 1381
        size = 2048
        buf_len = 1004
        buf = 0x81b3380
"--gQIIPDYu2UDVZoZv5NTp3DgT\r\n\r\nContent-Transfer-Encoding:
binary\r\nContent-ID:
<1231330858.sip:s5-1 at 10.6.2.246.596516649>\r\nContent-Type:
application/pidf+xml\r\n\r\n<?xml version=\"1.0\"
encoding=\"UTF-8\"?>\n<p"...
        auth_state = <value optimized out>
        contor = 1
        auth_state_flag = 2
        bstr = {s = 0x81b1970 "gQIIPDYu2UDVZoZv5NTp3DgT", len = 24}
        rlmi_cont = {
  s = 0x481aed98 "<?xml version=\"1.0\"?>\n<list
uri=\"sip:c5-1 at 10.6.2.246\" xmlns=\"urn:ietf:params:xml:ns:rlmi\"
version=\"5\" fullState=\"false\">\n  <resource
uri=\"sip:s5-1 at 10.6.2.246\">\n    <instance id=\"icDW4oK5\"
state=\"activ"..., len = 274}
        multi_cont = {
  s = 0x81b3380
"--gQIIPDYu2UDVZoZv5NTp3DgT\r\n\r\nContent-Transfer-Encoding:
binary\r\nContent-ID:
<1231330858.sip:s5-1 at 10.6.2.246.596516649>\r\nContent-Type:
application/pidf+xml\r\n\r\n<?xml version=\"1.0\"
encoding=\"UTF-8\"?>\n<p"..., len = 1004}
        s = (subs_t *) 0x77af7598
        dialog = (subs_t *) 0x81b31b0
        rl_uri = 0x81b2a80 "sip:c5-1 at 10.6.2.246"
        str_aux = <value optimized out>
        __FUNCTION__ = "timer_send_notify"
#3  0x080ccfb5 in start_timer_processes () at timer.c:280
---Type <return> to continue, or q <return> to quit---
        tpl = (struct sr_timer_process *) 0x81acad8
        pid = <value optimized out>
        first = <value optimized out>
        __FUNCTION__ = "start_timer_processes"
#4  0x0806f189 in main (argc=3, argv=0xbf9ad664) at main.c:666
        cfg_log_stderr = 0
        cfg_stream = (FILE *) 0x481a4008
        c = <value optimized out>
        r = <value optimized out>
        tmp = 0xbf9aedec ""
        tmp_len = <value optimized out>
        port = <value optimized out>
        proto = <value optimized out>
        ret = <value optimized out>
        seed = 4221279407
        rfd = 4
        __FUNCTION__ = "main"
(gdb)

crash 3 with full bt trace
===================
error message before crashing:
Jan  7 07:29:00 [10190] ERROR:db_mysql:db_mysql_str2val: invalid parameter
value
Jan  7 07:29:00 [10190] ERROR:db_mysql:db_mysql_convert_row: failed to
convert value
Jan  7 07:29:09 [10189] ERROR:core:db_do_insert: invalid parameter value
Jan  7 07:29:09 [10189] ERROR:pua:db_update: while inserting in db table
pua

Core was generated by `/usr/local/sbin/opensips -m 1024'.
Program terminated with signal 11, Segmentation fault.
#0  db_free_row (_r=0x81b79e8) at db/db_row.c:62
62                      switch (VAL_TYPE(_val)) {
(gdb) bt full
#0  db_free_row (_r=0x81b79e8) at db/db_row.c:62
        col = 0
        _val = (db_val_t *) 0x0
        __FUNCTION__ = "db_free_row"
#1  0xb7d9b580 in db_mysql_convert_row (_h=0x81b3820, _res=0x81ad938,
_r=0x81b79e8) at row.c:69
        lengths = (long unsigned int *) 0x481aebcc
        i = 135935876
        __FUNCTION__ = "db_mysql_convert_row"
#2  0xb7d9aeca in db_mysql_convert_result (_h=0x81b3820, _r=0x81ad938) at
res.c:171
        __FUNCTION__ = "db_mysql_convert_result"
#3  0xb7d98a2f in db_mysql_store_result (_h=0x81b3820, _r=0xbf9f4500) at
dbase.c:177
        __FUNCTION__ = "db_mysql_store_result"
#4  0x0811b94f in db_do_query (_h=0x81b3820, _k=0xbf9f44f4, _op=0x0,
_v=0xbf9f4474, _c=0xbf9f449c, _n=1, _nc=6, _o=0xb78e6834, _r=0xbf9f4500,
    val2str=0xb7d9b780 <db_mysql_val2str>, submit_query=0xb7d98de9
<db_mysql_submit_query>, store_result=0xb7d989c7 <db_mysql_store_result>)
    at db/db_query.c:105
        tmp = <value optimized out>
        off = 132
        ret = <value optimized out>
        __FUNCTION__ = "db_do_query"
#5  0xb7d97d05 in db_mysql_query (_h=0x81b3820, _k=0xbf9f44f4, _op=0x0,
_v=0xbf9f4474, _c=0xbf9f449c, _n=1, _nc=6, _o=0xb78e6834, _r=0xbf9f4500)
    at dbase.c:247
No locals.
#6  0xb78d4c75 in timer_send_notify (ticks=80, param=0x0) at
resource_notify.c:493
        query_cols = {0xb78e6844, 0x0}
        update_cols = {0xb78e6844}
        result_cols = {0xb78e6834, 0xb78e683c, 0xb78e684c, 0xb78e685c,
0xb78e6854, 0xb78e6864, 0x0}
        query_vals = {{type = DB_INT, nul = 0, free = 2007089048, val =
{int_val = 1, double_val = -2.766852607421637e-39, time_val = 1,
      string_val = 0x1 <Address 0x1 out of bounds>, str_val = {s = 0x1
<Address 0x1 out of bounds>, len = -1209130788}, blob_val = {
        s = 0x1 <Address 0x1 out of bounds>, len = -1209130788},
bitmap_val = 1}}, {type = 3085836512, nul = -1209131020, free = 310, val =
{int_val = 310,
      double_val = -0.03053575754165757, time_val = 310, string_val =
0x136 <Address 0x136 out of bounds>, str_val = {
        s = 0x136 <Address 0x136 out of bounds>, len = -1080081212},
blob_val = {s = 0x136 <Address 0x136 out of bounds>, len = -1080081212},
      bitmap_val = 310}}}
        update_vals = {{type = DB_DATETIME, nul = 2007089048, free =
-1080081152, val = {int_val = -1, double_val = -3.3348689399357007e-39,
time_val = -1,
      string_val = 0xffffffff <Address 0xffffffff out of bounds>, str_val
= {s = 0xffffffff <Address 0xffffffff out of bounds>, len = -1208866784},
      blob_val = {s = 0xffffffff <Address 0xffffffff out of bounds>, len =
-1208866784}, bitmap_val = 4294967295}}}
        i = <value optimized out>
        result = (db_res_t *) 0x81ad938
        prev_did = <value optimized out>
        curr_did = <value optimized out>
        row_vals = <value optimized out>
        resource_uri = <value optimized out>
        pres_state = <value optimized out>
        callid = {s = 0x0, len = 0}
        to_tag = {s = 0x481c67ed
"h\034H_h\034H`h\034H?k\034Hc3-2-80;210632768;97b57f2144c425bc44f2e7a21eb22549-f3e9",
len = 79}
        from_tag = {s = 0x481c67e4
"4h\034HHh\034HJh\034H_h\034H`h\034H?k\034Hc3-2-80;210632768;97b57f2144c425bc44f2e7a21eb22549-f3e9",
len = 8}
        rlmi_doc = <value optimized out>
        list_node = <value optimized out>
        instance_node = <value optimized out>
        resource_node = <value optimized out>
        hash_code = <value optimized out>
        size = <value optimized out>
        buf_len = <value optimized out>
        buf = <value optimized out>
        auth_state = <value optimized out>
        contor = <value optimized out>
        auth_state_flag = <value optimized out>
        bstr = {s = 0x0, len = 0}
---Type <return> to continue, or q <return> to quit---
        rlmi_cont = {s = 0x0, len = 0}
        multi_cont = {s = 0x0, len = 8}
        s = <value optimized out>
        dialog = <value optimized out>
        rl_uri = <value optimized out>
        str_aux = <value optimized out>
        __FUNCTION__ = "timer_send_notify"
#7  0x080ccfb5 in start_timer_processes () at timer.c:280
        tpl = (struct sr_timer_process *) 0x81acad8
        pid = <value optimized out>
        first = <value optimized out>
        __FUNCTION__ = "start_timer_processes"
#8  0x0806f189 in main (argc=3, argv=0xbf9f46b4) at main.c:666
        cfg_log_stderr = 0
        cfg_stream = (FILE *) 0x481a4008
        c = <value optimized out>
        r = <value optimized out>
        tmp = 0xbf9f5dec ""
        tmp_len = <value optimized out>
        port = <value optimized out>
        proto = <value optimized out>
        ret = <value optimized out>
        seed = 3089561270
        rfd = 4
        __FUNCTION__ = "main"
(gdb)



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

Comment By: Nathan (rmnathan)
Date: 2009-01-07 14:15

Message:
Hi
the full trace as follows 
 
Core was generated by `/usr/local/sbin/opensips'.
Program terminated with signal 11, Segmentation fault.
#0  0xb78e7eca in timer_send_notify (ticks=120, param=0x0) at
resource_notify.c:721
721                            
if(strncmp(row_vals[resource_uri_col].val.string_val,
(gdb) bt full
#0  0xb78e7eca in timer_send_notify (ticks=120, param=0x0) at
resource_notify.c:721
        query_cols = {0xb78f8844, 0xb7aab510}
        update_cols = {0x0}
        result_cols = {0xb78f8834, 0xb78f883c, 0xb78f884c, 0xb78f885c,
0xb78f8854, 0xb78f8864, 0x0}
        query_vals = {{type = DB_INT, nul = 0, free = -1247617128, val =
{int_val = 1, double_val = 4.2439915824246103e-314, time_val = 1,
      string_val = 0x1 <Address 0x1 out of bounds>, str_val = {s = 0x1
<Address 0x1 out of bounds>, len = 2}, blob_val = {
        s = 0x1 <Address 0x1 out of bounds>, len = 2}, bitmap_val = 1}},
{type = DB_DOUBLE, nul = 0, free = -1081894044, val = {int_val = 135974160,
      double_val = 6.7180161178120992e-316, time_val = 135974160,
string_val = 0x81acd10 "??????\032\b", str_val = {s = 0x81acd10
"??????\032\b", len = 0},
      blob_val = {s = 0x81acd10 "??????\032\b", len = 0}, bitmap_val
= 135974160}}}
        update_vals = {{type = DB_DATETIME, nul = -1247617128, free =
-1243838944, val = {int_val = -1213549416, double_val =
-1.5328670054899573e-40,
      time_val = -1213549416, string_val = 0xb7aab498 "?S??\006",
str_val = {s = 0xb7aab498 "?S??\006", len = -1213549360}, blob_val = {
        s = 0xb7aab498 "?S??\006", len = -1213549360}, bitmap_val =
3081417880}}}
        i = 298
        result = (db_res_t *) 0x828f678
        prev_did = 0x4821159c
"s6-13-80;100595200;97b57f2144c425bc44f2e7a21eb22549-1265"
        curr_did = 0x48211d5c
"s6-14-80;218035712;97b57f2144c425bc44f2e7a21eb22549-365a"
        row_vals = (db_val_t *) 0x64697072
        resource_uri = <value optimized out>
        pres_state = 0x48211dc2 "<?xml version=\"1.0\"
encoding=\"UTF-8\"?>\n<presence xmlns=\"urn:ietf:params:xml:ns:pidf\"
xmlns:rpid=\"urn:ietf:params:xml:ns:pidf:rpid\"
xmlns:dm=\"urn:ietf:params:xml:ns:pidf:data-model\"
xmlns:pcp=\"urn:ietf"...
        callid = {s = 0x48211d5c
"s6-14-80;218035712;97b57f2144c425bc44f2e7a21eb22549-365a", len = 8}
        to_tag = {s = 0x48211d6f "97b57f2144c425bc44f2e7a21eb22549-365a",
len = 37}
        from_tag = {s = 0x48211d65
"218035712;97b57f2144c425bc44f2e7a21eb22549-365a", len = 9}
        rlmi_doc = (xmlDocPtr) 0x481aec20
        list_node = (xmlNodePtr) 0x481accb8
        instance_node = (xmlNodePtr) 0x481f0da0
        resource_node = (xmlNodePtr) 0x481af8c0
        hash_code = 349
        size = 6144
        buf_len = 1007
        buf = 0x8298040
"--uiJUnfDUyfcSFWRINqnYyVEx\r\n\r\nContent-Transfer-Encoding:
binary\r\nContent-ID:
<1231322726.sip:c6-18 at 10.6.2.246.596516649>\r\nContent-Type:
application/pidf+xml\r\n\r\n<?xml version=\"1.0\"
encoding=\"UTF-8\"?>\n<"...
        auth_state = <value optimized out>
        contor = 1
        auth_state_flag = <value optimized out>
        bstr = {s = 0x8292c30 "uiJUnfDUyfcSFWRINqnYyVEx", len = 24}
        rlmi_cont = {
  s = 0x481f0fd8 "pT??pT???\017\037H?\017\037H.0\"?>\n<list
uri=\"sip:s6-13 at 10.6.2.246\" xmlns=\"urn:ietf:params:xml:ns:rlmi\"
version=\"2\" fullState=\"false\">\n  <resource
uri=\"sip:c6-17 at 10.6.2.246\">\n    <instance id=\"icDW4oK5\"
state=\"act"..., len = 959}
        multi_cont = {
  s = 0x8298040
"--uiJUnfDUyfcSFWRINqnYyVEx\r\n\r\nContent-Transfer-Encoding:
binary\r\nContent-ID:
<1231322726.sip:c6-18 at 10.6.2.246.596516649>\r\nContent-Type:
application/pidf+xml\r\n\r\n<?xml version=\"1.0\"
encoding=\"UTF-8\"?>\n<"..., len = 6053}
        s = (subs_t *) 0xb602c300
        dialog = (subs_t *) 0x81a7ef0
        rl_uri = 0x8291670 "sip:s6-14 at 10.6.2.246"
        str_aux = <value optimized out>
        __FUNCTION__ = "timer_send_notify"
#1  0x080ccfb5 in start_timer_processes () at timer.c:280
        tpl = (struct sr_timer_process *) 0x81acad8
        pid = <value optimized out>
        first = <value optimized out>
        __FUNCTION__ = "start_timer_processes"
#2  0x0806f189 in main (argc=1, argv=0xbf839d14) at main.c:666
        cfg_log_stderr = 0
        cfg_stream = (FILE *) 0x481a4008
        c = <value optimized out>
        r = <value optimized out>
---Type <return> to continue, or q <return> to quit---
        tmp = 0x8166200 "\034a\026\bhF??@???"
        tmp_len = <value optimized out>
        port = <value optimized out>
        proto = <value optimized out>
        ret = <value optimized out>
        seed = 82752229
        rfd = 4
        __FUNCTION__ = "main"
(gdb)

Regards,
rmnathan

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

Comment By: Nobody/Anonymous (nobody)
Date: 2009-01-07 13:04

Message:
It would help to provide the backtrace with the full context and the value
of the local variables. To do that use "bt full" instead of just "bt".

Dan


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

Comment By: Nathan (rmnathan)
Date: 2009-01-07 12:40

Message:
Hi Anca,
I observed few crashes as follows while testing with new trunck build.

Crash 1:
======
Core was generated by `/usr/local/sbin/opensips -m 1024'.
Program terminated with signal 11, Segmentation fault.
#0  0xb7e18d00 in strncmp () from /lib/libc.so.6
(gdb) bt
#0  0xb7e18d00 in strncmp () from /lib/libc.so.6
#1  0xb78cfee3 in timer_send_notify (ticks=40, param=0x0) at
resource_notify.c:721
#2  0x080ccfb5 in start_timer_processes () at timer.c:280
#3  0x0806f189 in main (argc=3, argv=0xbfb57014) at main.c:666

Crash 2:
======
Program terminated with signal 11, Segmentation fault.
#0  fm_malloc (qm=0x81a3ba0, size=2640) at mem/f_malloc.c:267
267                             if ((*f)->size>=size) goto found;
(gdb) bt
#0  fm_malloc (qm=0x81a3ba0, size=2640) at mem/f_malloc.c:267
#1  0xb78dcb51 in agg_body_sendn_update (rl_uri=0x81a7ef0,
boundary_string={s = 0x81dadc0 "j5dDEBAL5H1LAtor2qUGI2ac", len = 24},
rlmi_body=0xbfef61d4,
    multipart_body=0xbfef61cc, subs=0x81a7ef0, hash_code=1978) at
notify.c:238
#2  0xb78dfefe in timer_send_notify (ticks=60, param=0x0) at
resource_notify.c:544
#3  0x080ccfb5 in start_timer_processes () at timer.c:280
#4  0x0806f189 in main (argc=3, argv=0xbfef63b4) at main.c:666

crash 3:
======
#0  0xb78e7eca in timer_send_notify (ticks=120, param=0x0) at
resource_notify.c:721
721                            
if(strncmp(row_vals[resource_uri_col].val.string_val,
(gdb) bt
#0  0xb78e7eca in timer_send_notify (ticks=120, param=0x0) at
resource_notify.c:721
#1  0x080ccfb5 in start_timer_processes () at timer.c:280
#2  0x0806f189 in main (argc=1, argv=0xbf839d14) at main.c:666

crash 4:
======
Core was generated by `/usr/local/sbin/opensips -m 1024'.
Program terminated with signal 11, Segmentation fault.
#0  db_free_row (_r=0x81c25d0) at db/db_row.c:62
62                      switch (VAL_TYPE(_val)) {

crash 5:
======
Core was generated by `/usr/local/sbin/opensips'.
Program terminated with signal 11, Segmentation fault.
#0  0x080f9282 in parse_uri (buf=0x8 <Address 0x8 out of bounds>,
len=135995841, uri=0xbf9fbfe0) at parser/parse_uri.c:329
329             scheme=buf[0]+(buf[1]<<8)+(buf[2]<<16)+(buf[3]<<24);


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

Comment By: Anca Vamanu (anca_vamanu)
Date: 2009-01-06 16:41

Message:
Hi Meganathan,

I think that I have finally found the bug this time. Can you please
update, test again and confirm?

Thanks and regards,
Anca

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

Comment By: Nathan (rmnathan)
Date: 2008-12-31 11:37

Message:
Hi Anca,
 Any update on this issue?

Regards,
Meganathan.

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

Comment By: Nathan (rmnathan)
Date: 2008-12-18 16:45

Message:
Hi Anca 
 I have retested with latest build (rev 5071). Again I got the crash  

(gdb) bt
#0  0xb7e1861d in _IO_str_overflow () from /lib/libc.so.6
#1  0xb7e17747 in _IO_default_xsputn () from /lib/libc.so.6
#2  0xb7deea94 in vfprintf () from /lib/libc.so.6
#3  0xb7e0c92c in vsprintf () from /lib/libc.so.6
#4  0xb7df775e in sprintf () from /lib/libc.so.6
#5  0xb78d810b in timer_send_notify (ticks=40, param=0x0) at
resource_notify.c:700
#6  0x080ccb55 in start_timer_processes () at timer.c:280
#7  0x0806ef69 in main (argc=1, argv=0xbfa78f44) at main.c:666

Regards,
rmnathan


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

Comment By: Anca Vamanu (anca_vamanu)
Date: 2008-12-18 14:28

Message:
Hi rmnathan,

I have made some changes in the rls module. 
Can you please update and test again?

regards,
Anca

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

Comment By: Nathan (rmnathan)
Date: 2008-12-16 12:12

Message:
Hi Anca,
After i compiled with following commands i got core dump with line
numbers.

make
echo $?
make prefix=/usr/local/ install

Program terminated with signal 11, Segmentation fault.
#0  0xb7e5161d in _IO_str_overflow () from /lib/libc.so.6
(gdb) bt
#0  0xb7e5161d in _IO_str_overflow () from /lib/libc.so.6
#1  0xb7e50747 in _IO_default_xsputn () from /lib/libc.so.6
#2  0xb7e27a94 in vfprintf () from /lib/libc.so.6
#3  0xb7e4592c in vsprintf () from /lib/libc.so.6
#4  0xb7e3075e in sprintf () from /lib/libc.so.6
#5  0xb7911d53 in timer_send_notify (ticks=40, param=0x0) at
resource_notify.c:687
#6  0x080ccb55 in start_timer_processes () at timer.c:280
#7  0x0806ef69 in main (argc=1, argv=0xbf805cf4) at main.c:666

regards,
rmnathan


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

Comment By: Nathan (rmnathan)
Date: 2008-12-16 11:45

Message:
Hi Anca,
I have tried with latest trunk build (rev 5060), am getting the same
crash.
I have set 'ulimit -c unlimited' also but the line numbers not getting
printed.

Core was generated by `opensips'.
Program terminated with signal 11, Segmentation fault.
#0  0xb7ec161d in _IO_str_overflow () from /lib/libc.so.6
(gdb) bt
#0  0xb7ec161d in _IO_str_overflow () from /lib/libc.so.6
#1  0xb7ec0747 in _IO_default_xsputn () from /lib/libc.so.6
#2  0xb7e97a94 in vfprintf () from /lib/libc.so.6
#3  0xb7eb592c in vsprintf () from /lib/libc.so.6
#4  0xb7ea075e in sprintf () from /lib/libc.so.6
#5  0xb799a25d in timer_send_notify () from
/usr/local//lib/opensips/modules/rls.so
#6  0x080b1194 in timer_ticker ()
#7  0x080b0fc5 in run_timer_process ()
#8  0x080b12ff in start_timer_processes ()
#9  0x08065cdd in main_loop ()
#10 0x08067f53 in main ()

Regards
rmnathan

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

Comment By: Anca Vamanu (anca_vamanu)
Date: 2008-12-15 16:19

Message:
Hi rmnathan,

I have tested myself and got a crash after some time - it was due to a
recent change that I made. I have commited the fix in trunk.
However I am not really sure it is the same as you have seen, as in your
trace there isn't enough information -like line numbers. Can you please
update and test again and report if you see the crash again. 
Btw, have you run: 'ulimit -c unlimited'?

regards,
Anca 


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

Comment By: Nathan (rmnathan)
Date: 2008-12-15 13:17

Message:
Finally core has created. Please see below

stinbng46:/# gdb /usr/local/sbin/opensips core
GNU gdb 6.4.90-debian
Copyright (C) 2006 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you
are
welcome to change it and/or distribute copies of it under certain
conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for
details.
This GDB was configured as "i486-linux-gnu"...Using host libthread_db
library "/lib/libthread_db.so.1".


warning: Can't read pathname for load map: Input/output error.
Reading symbols from /lib/libdl.so.2...done.
Loaded symbols for /lib/libdl.so.2
Reading symbols from /lib/libresolv.so.2...done.
Loaded symbols for /lib/libresolv.so.2
Reading symbols from /lib/libc.so.6...done.
Loaded symbols for /lib/libc.so.6
Reading symbols from /lib/ld-linux.so.2...done.
Loaded symbols for /lib/ld-linux.so.2
Reading symbols from /usr/local/lib/opensips/modules/db_mysql.so...done.
Loaded symbols for /usr/local//lib/opensips/modules/db_mysql.so
Reading symbols from /usr/lib/libmysqlclient.so.15...done.
Loaded symbols for /usr/lib/libmysqlclient.so.15
Reading symbols from /lib/libpthread.so.0...done.
Loaded symbols for /lib/libpthread.so.0
Reading symbols from /lib/libcrypt.so.1...done.
Loaded symbols for /lib/libcrypt.so.1
Reading symbols from /lib/libnsl.so.1...done.
Loaded symbols for /lib/libnsl.so.1
Reading symbols from /lib/libm.so.6...done.
Loaded symbols for /lib/libm.so.6
Reading symbols from /usr/lib/libz.so.1...done.
Loaded symbols for /usr/lib/libz.so.1
Reading symbols from /usr/local/lib/opensips/modules/sl.so...done.
Loaded symbols for /usr/local//lib/opensips/modules/sl.so
Reading symbols from /usr/local/lib/opensips/modules/maxfwd.so...done.
Loaded symbols for /usr/local//lib/opensips/modules/maxfwd.so
Reading symbols from /usr/local/lib/opensips/modules/textops.so...done.
Loaded symbols for /usr/local//lib/opensips/modules/textops.so
Reading symbols from /usr/local/lib/opensips/modules/tm.so...done.
Loaded symbols for /usr/local//lib/opensips/modules/tm.so
Reading symbols from /usr/local/lib/opensips/modules/rr.so...done.
Loaded symbols for /usr/local//lib/opensips/modules/rr.so
Reading symbols from /usr/local/lib/opensips/modules/presence.so...done.
Loaded symbols for /usr/local//lib/opensips/modules/presence.so
Reading symbols from /usr/lib/libxml2.so.2...done.
Loaded symbols for /usr/lib/libxml2.so.2
Reading symbols from /usr/local/lib/opensips/modules/avpops.so...done.
Loaded symbols for /usr/local//lib/opensips/modules/avpops.so
Reading symbols from /usr/local/lib/opensips/modules/pua.so...done.
Loaded symbols for /usr/local//lib/opensips/modules/pua.so
Reading symbols from /usr/local/lib/opensips/modules/mi_fifo.so...done.
Loaded symbols for /usr/local//lib/opensips/modules/mi_fifo.so
Reading symbols from
/usr/local/lib/opensips/modules/presence_xml.so...done.
Loaded symbols for /usr/local//lib/opensips/modules/presence_xml.so
Reading symbols from /usr/local/lib/opensips/modules/rls.so...done.
Loaded symbols for /usr/local//lib/opensips/modules/rls.so
Reading symbols from /usr/local/lib/opensips/modules/xlog.so...done.
Loaded symbols for /usr/local//lib/opensips/modules/xlog.so
Reading symbols from /usr/local/lib/opensips/modules/signaling.so...done.
Loaded symbols for /usr/local//lib/opensips/modules/signaling.so
Reading symbols from /lib/libnss_db.so.2...done.
Loaded symbols for /lib/libnss_db.so.2
Reading symbols from /lib/libnss_files.so.2...done.
Loaded symbols for /lib/libnss_files.so.2
Reading symbols from /usr/lib/libdb3.so.3...done.
Loaded symbols for /usr/lib/libdb3.so.3
Core was generated by `/usr/local/sbin/opensips -D'.
Program terminated with signal 11, Segmentation fault.
#0  0xb7e9f61d in _IO_str_overflow () from /lib/libc.so.6
(gdb) bt
#0  0xb7e9f61d in _IO_str_overflow () from /lib/libc.so.6
#1  0xb7e9e747 in _IO_default_xsputn () from /lib/libc.so.6
#2  0xb7e75a94 in vfprintf () from /lib/libc.so.6
#3  0xb7e9392c in vsprintf () from /lib/libc.so.6
#4  0xb7e7e75e in sprintf () from /lib/libc.so.6
#5  0xb7978256 in timer_send_notify () from
/usr/local//lib/opensips/modules/rls.so
#6  0x080b11a0 in timer_ticker ()
#7  0x080b0fd1 in run_timer_process ()
#8  0x080b130b in start_timer_processes ()
#9  0x08065cdd in main_loop ()
#10 0x08067f5f in main ()

Regards
rmnathan


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

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


From bogdan at voice-system.ro  Fri Feb  6 19:39:05 2009
From: bogdan at voice-system.ro (Bogdan-Andrei Iancu)
Date: Fri, 06 Feb 2009 18:39:05 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[5257] trunk
Message-ID: <E1LVVbV-0000AT-0r@74yxhf1.ch3.sourceforge.com>

Revision: 5257
          http://opensips.svn.sourceforge.net/opensips/?rev=5257&view=rev
Author:   bogdan_iancu
Date:     2009-02-06 18:39:04 +0000 (Fri, 06 Feb 2009)

Log Message:
-----------
1) if stateless fwd functions (like forward) are not used in script, the OpenSIPS core will automatically drop all replies that needs to be statelessly FWD.
-> if only TM forwarding is done in script, the core will not statelessly fwd any reply.

2) new core param DISABLE_STATELESS_FWD to force the dropping of stateless replies.

Modified Paths:
--------------
    trunk/cfg.lex
    trunk/cfg.y
    trunk/forward.c
    trunk/globals.h
    trunk/main.c
    trunk/route.c


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


From bogdan at voice-system.ro  Fri Feb  6 19:44:39 2009
From: bogdan at voice-system.ro (Bogdan-Andrei Iancu)
Date: Fri, 06 Feb 2009 20:44:39 +0200
Subject: [OpenSIPS-Devel] OpenSIPS @ UKNOF
Message-ID: <498C8517.7020709@voice-system.ro>

Hello,


On 13th of February 2009, I will keep a presentation for OpenSIPS 
project at UKNOF (http://www.uknof.org.uk/index.html) 12th edition. The 
event will take place in Bristol, UK.

The topic is how current network operators can use and benefit of VoIP 
services built on top of *OpenSIPS*/*OpenSER* - is an Open Source 
platform attractive and robust enough for their demands?

See here the full agenda of the event: http://www.uknof.org.uk/uknof12/


Regards,
Bogdan



From bogdan at voice-system.ro  Fri Feb  6 19:51:11 2009
From: bogdan at voice-system.ro (Bogdan-Andrei Iancu)
Date: Fri, 06 Feb 2009 20:51:11 +0200
Subject: [OpenSIPS-Devel] [NEW] auto-disabling of stateless reply forwarding
Message-ID: <498C869F.8020007@voice-system.ro>

Hi,

I just commited a new functionality in OpenSIPS that will make it more 
safe in operation.

The idea is simple: if you do not statelessly forward any request (via 
forward() function), the core will also not forward any stateless reply.

This is automatically detected (by inspecting the script and looking for 
stateless fwd functions), so you do not have to change anything in the 
cfg in order to enable it.

Most of the scripts are stateful (using only TM to forward requests), so 
there are no stateless replies to forward -> OpenSIPS will protect 
itself (and refuse to become a reply relay) and drop all stateless replies.

Regards,
Bogdan


From noreply at sourceforge.net  Sat Feb  7 01:23:53 2009
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat, 07 Feb 2009 00:23:53 +0000
Subject: [OpenSIPS-Devel] [ opensips-Bugs-2538399 ] Bug in presence when
	using fallback2db
Message-ID: <E1LVazB-0006tD-04@d45xhf1.ch3.sourceforge.com>

Bugs item #2538399, was opened at 2009-01-26 14:39
Message generated for change (Comment added) made by oren_k
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=2538399&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: Oren K (oren_k)
Assigned to: Anca Vamanu (anca_vamanu)
Summary: Bug in presence when using fallback2db

Initial Comment:
Hi,

While using the presence module, I run this scenario:

a. user1 SUBSCRIBE's to presence of user2
(subscription is now pending)

b. user2 allows user1 in pres-rules
(refreshWatchers is called, subscription is now active. user1 receives a NOTIFY from presence server with user2's current tuple and Subscription-State: active)

c. user2 PUBLISH'es a new presence tuple
-- at this point presence server should NOTIFY user1 of the new presence but it doesn't (that's the bug).


My modparams:

modparam("presence|presence_xml", "db_url", "mysql://root at localhost/opensips")

modparam("presence", "server_address", "sip:presence.example.com:10500")

modparam("presence", "fallback2db", 1)
modparam("presence", "clean_period", 30)


What I see in the debug trace is that get_subs_dialog (from notify.c) can't find any dialogs in the database, and all those in the subs hash are flagged NO_UPDATEDB_FLAG. This is probably what's causing the problem. 
Strangely, in the above scenario if user1 un-SUBSCRIBEs and re-SUBSCRIBEs to user2's presence - it does receive notifications.

Regards,
Oren K.

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

>Comment By: Oren K (oren_k)
Date: 2009-02-06 19:23

Message:
Hi Anca,

I've attached a debug-log and wireshark pcap file to the post. The pcap
file also contains the XCAP PUTs to change the presence rules. The only
error in the log comes from presence_xml not being able to extract a tuple
node because our client uses <pdm:person> for the presence (Same bug
happened to us when we tried with <tuple> so that's not the issue). The
things that strike me odd in presence_bug.log are:

(after step b. user2 allows user1 in pres-rules)
line 634: DBG:presence:update_pw_dialogs: found 1 matching dialogs

the module finds the watcher dialog and updates it due to refreshWatchers.
user1 receives a NOTIFY with Subscription-State:active. Now step c. user2
PUBLISH'es a new presence tuple:

line 919: DBG:core:parse_msg:  method:  <PUBLISH>

everything looks okay BUT:

line 1087: DBG:presence:get_subs_db: The query for subscribtion for [uri]=
sip:user2 at openims.summit-tech.ca for [event]= presence returned no result
line 1110: DBG:presence:get_subs_dialog: s->db_flag== UPDATEDB_FLAG
line 1111: DBG:presence:get_subs_dialog: found 0 dialogs( 0 in database
and 0 in hash_table)
line 1112: DBG:presence:publ_notify: Could not find subs_dialog

..suddenly there are no subscribers?

Thanks.


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

Comment By: Anca Vamanu (anca_vamanu)
Date: 2009-02-06 13:14

Message:
Hi Oren,

I have just downloaded myself the release and tested and the scenario that
you described works. 
Do you notice any error in your log file?

regards,
Anca

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

Comment By: Oren K (oren_k)
Date: 2009-02-01 11:41

Message:
Sorry I forgot to login, that comment is from me :)

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

Comment By: Nobody/Anonymous (nobody)
Date: 2009-01-28 10:12

Message:
Thanks for the reply anca. Version is opensips-1.4.4-tls, compiled from the
sources with TLS="1". 

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

Comment By: Anca Vamanu (anca_vamanu)
Date: 2009-01-28 06:48

Message:
Hi Oren,

What OpenSIPS version are you using? Trunk or stable release?

regards,
Anca

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

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


From bogdan at voice-system.ro  Sat Feb  7 09:23:49 2009
From: bogdan at voice-system.ro (Bogdan-Andrei Iancu)
Date: Sat, 07 Feb 2009 08:23:49 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[5258] trunk
Message-ID: <E1LViTd-0003Jw-3K@c3vjzd1.ch3.sourceforge.com>

Revision: 5258
          http://opensips.svn.sourceforge.net/opensips/?rev=5258&view=rev
Author:   bogdan_iancu
Date:     2009-02-07 08:23:48 +0000 (Sat, 07 Feb 2009)

Log Message:
-----------
- code formating only

Modified Paths:
--------------
    trunk/modules/msilo/msfuncs.c
    trunk/modules/msilo/msilo.c
    trunk/parser/parse_fline.h


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


From bogdan at voice-system.ro  Sat Feb  7 09:24:50 2009
From: bogdan at voice-system.ro (Bogdan-Andrei Iancu)
Date: Sat, 07 Feb 2009 08:24:50 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[5259] trunk/modules/imc/imc.c
Message-ID: <E1LViUc-0003Kx-PW@c3vjzd1.ch3.sourceforge.com>

Revision: 5259
          http://opensips.svn.sourceforge.net/opensips/?rev=5259&view=rev
Author:   bogdan_iancu
Date:     2009-02-07 08:24:50 +0000 (Sat, 07 Feb 2009)

Log Message:
-----------
- removed unused include

Modified Paths:
--------------
    trunk/modules/imc/imc.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 Feb  7 10:08:05 2009
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat, 07 Feb 2009 09:08:05 +0000
Subject: [OpenSIPS-Devel] [ opensips-Patches-2564149 ] mysql performance
	enhancements
Message-ID: <E1LVjAT-0007yQ-6l@3bkjzd1.ch3.sourceforge.com>

Patches item #2564149, was opened at 2009-02-04 16:23
Message generated for change (Settings changed) made by bogdan_iancu
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086412&aid=2564149&group_id=232389

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: modules
Group: trunk
>Status: Closed
>Resolution: Accepted
Priority: 5
Private: No
Submitted By: Unix Dev (psystar)
Assigned to: Bogdan-Andrei Iancu (bogdan_iancu)
Summary: mysql performance enhancements

Initial Comment:
Changed all mysql types from varchar to char in order to change table type from 'dynamic' to 'fixed'. Note, some tables are still dynamic due to specific data types, blob, text, etc.

Version numbers for tables have been incremented.

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

>Comment By: Bogdan-Andrei Iancu (bogdan_iancu)
Date: 2009-02-07 11:07

Message:
Hi,

I applied the patch. However, the patch was incomplete - the table
versions were changed in the DB schema, but not in the modules :). I
updated this also.

Thanks and regards,
Bogdan

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

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


From bogdan at voice-system.ro  Sat Feb  7 10:12:04 2009
From: bogdan at voice-system.ro (Bogdan-Andrei Iancu)
Date: Sat, 07 Feb 2009 09:12:04 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[5260] trunk
Message-ID: <E1LVjEK-0001FV-5S@dn4whf1.ch3.sourceforge.com>

Revision: 5260
          http://opensips.svn.sourceforge.net/opensips/?rev=5260&view=rev
Author:   bogdan_iancu
Date:     2009-02-07 09:12:03 +0000 (Sat, 07 Feb 2009)

Log Message:
-----------
Changed all mysql types from varchar to char in order to change table type from 'dynamic' to 'fixed'. Note, some tables are still dynamic due to specific data types, blob, text, etc.

This change affects only MySQL database (as structure).

Version of all tables was increased.

DB schema re-generated.

Credits goto UnixDev - closes patches 2564149.

Modified Paths:
--------------
    trunk/config.h
    trunk/db/schema/acc.xml
    trunk/db/schema/address.xml
    trunk/db/schema/aliases.xml
    trunk/db/schema/carrierfailureroute.xml
    trunk/db/schema/carrierroute.xml
    trunk/db/schema/cpl.xml
    trunk/db/schema/dbaliases.xml
    trunk/db/schema/dialog.xml
    trunk/db/schema/dialplan.xml
    trunk/db/schema/dispatcher.xml
    trunk/db/schema/domain.xml
    trunk/db/schema/domainpolicy.xml
    trunk/db/schema/dr_gateways.xml
    trunk/db/schema/dr_groups.xml
    trunk/db/schema/dr_rules.xml
    trunk/db/schema/globalblacklist.xml
    trunk/db/schema/grp.xml
    trunk/db/schema/gw.xml
    trunk/db/schema/imc_members.xml
    trunk/db/schema/imc_rooms.xml
    trunk/db/schema/lcr.xml
    trunk/db/schema/location.xml
    trunk/db/schema/missed_calls.xml
    trunk/db/schema/pdt.xml
    trunk/db/schema/pr_active_watchers.xml
    trunk/db/schema/pr_presentity.xml
    trunk/db/schema/pr_pua.xml
    trunk/db/schema/pr_watchers.xml
    trunk/db/schema/pr_xcap.xml
    trunk/db/schema/re_grp.xml
    trunk/db/schema/rls_watchers.xml
    trunk/db/schema/route_tree.xml
    trunk/db/schema/silo.xml
    trunk/db/schema/sip_trace.xml
    trunk/db/schema/speed_dial.xml
    trunk/db/schema/subscriber.xml
    trunk/db/schema/template.xml
    trunk/db/schema/trusted.xml
    trunk/db/schema/uri.xml
    trunk/db/schema/userblacklist.xml
    trunk/db/schema/usr_preferences.xml
    trunk/modules/carrierroute/carrierroute.h
    trunk/modules/cpl-c/cpl_db.c
    trunk/modules/dialog/dlg_db_handler.h
    trunk/modules/dialplan/dp_db.h
    trunk/modules/dispatcher/dispatch.c
    trunk/modules/domain/domain_mod.c
    trunk/modules/domainpolicy/domainpolicy_mod.c
    trunk/modules/group/group_mod.c
    trunk/modules/lcr/lcr_mod.c
    trunk/modules/msilo/msilo.c
    trunk/modules/permissions/address.c
    trunk/modules/permissions/trusted.c
    trunk/modules/presence/presence.c
    trunk/modules/presence_xml/presence_xml.c
    trunk/modules/pua/pua.c
    trunk/modules/rls/rls.c
    trunk/modules/userblacklist/db.c
    trunk/modules/usrloc/ul_mod.h
    trunk/modules/xcap_client/xcap_client.c
    trunk/scripts/db_berkeley/opensips/version
    trunk/scripts/dbtext/opensips/version
    trunk/scripts/mysql/acc-create.sql
    trunk/scripts/mysql/alias_db-create.sql
    trunk/scripts/mysql/auth_db-create.sql
    trunk/scripts/mysql/avpops-create.sql
    trunk/scripts/mysql/carrierroute-create.sql
    trunk/scripts/mysql/cpl-create.sql
    trunk/scripts/mysql/dialog-create.sql
    trunk/scripts/mysql/dialplan-create.sql
    trunk/scripts/mysql/dispatcher-create.sql
    trunk/scripts/mysql/domain-create.sql
    trunk/scripts/mysql/domainpolicy-create.sql
    trunk/scripts/mysql/drouting-create.sql
    trunk/scripts/mysql/group-create.sql
    trunk/scripts/mysql/imc-create.sql
    trunk/scripts/mysql/lcr-create.sql
    trunk/scripts/mysql/msilo-create.sql
    trunk/scripts/mysql/pdt-create.sql
    trunk/scripts/mysql/permissions-create.sql
    trunk/scripts/mysql/presence-create.sql
    trunk/scripts/mysql/registrar-create.sql
    trunk/scripts/mysql/rls-create.sql
    trunk/scripts/mysql/siptrace-create.sql
    trunk/scripts/mysql/speeddial-create.sql
    trunk/scripts/mysql/standard-create.sql
    trunk/scripts/mysql/uri_db-create.sql
    trunk/scripts/mysql/userblacklist-create.sql
    trunk/scripts/mysql/usrloc-create.sql
    trunk/scripts/oracle/acc-create.sql
    trunk/scripts/oracle/alias_db-create.sql
    trunk/scripts/oracle/auth_db-create.sql
    trunk/scripts/oracle/avpops-create.sql
    trunk/scripts/oracle/carrierroute-create.sql
    trunk/scripts/oracle/cpl-create.sql
    trunk/scripts/oracle/dialog-create.sql
    trunk/scripts/oracle/dialplan-create.sql
    trunk/scripts/oracle/dispatcher-create.sql
    trunk/scripts/oracle/domain-create.sql
    trunk/scripts/oracle/domainpolicy-create.sql
    trunk/scripts/oracle/drouting-create.sql
    trunk/scripts/oracle/group-create.sql
    trunk/scripts/oracle/imc-create.sql
    trunk/scripts/oracle/lcr-create.sql
    trunk/scripts/oracle/msilo-create.sql
    trunk/scripts/oracle/pdt-create.sql
    trunk/scripts/oracle/permissions-create.sql
    trunk/scripts/oracle/presence-create.sql
    trunk/scripts/oracle/registrar-create.sql
    trunk/scripts/oracle/rls-create.sql
    trunk/scripts/oracle/siptrace-create.sql
    trunk/scripts/oracle/speeddial-create.sql
    trunk/scripts/oracle/uri_db-create.sql
    trunk/scripts/oracle/userblacklist-create.sql
    trunk/scripts/oracle/usrloc-create.sql
    trunk/scripts/postgres/acc-create.sql
    trunk/scripts/postgres/alias_db-create.sql
    trunk/scripts/postgres/auth_db-create.sql
    trunk/scripts/postgres/avpops-create.sql
    trunk/scripts/postgres/carrierroute-create.sql
    trunk/scripts/postgres/cpl-create.sql
    trunk/scripts/postgres/dialog-create.sql
    trunk/scripts/postgres/dialplan-create.sql
    trunk/scripts/postgres/dispatcher-create.sql
    trunk/scripts/postgres/domain-create.sql
    trunk/scripts/postgres/domainpolicy-create.sql
    trunk/scripts/postgres/drouting-create.sql
    trunk/scripts/postgres/group-create.sql
    trunk/scripts/postgres/imc-create.sql
    trunk/scripts/postgres/lcr-create.sql
    trunk/scripts/postgres/msilo-create.sql
    trunk/scripts/postgres/pdt-create.sql
    trunk/scripts/postgres/permissions-create.sql
    trunk/scripts/postgres/presence-create.sql
    trunk/scripts/postgres/registrar-create.sql
    trunk/scripts/postgres/rls-create.sql
    trunk/scripts/postgres/siptrace-create.sql
    trunk/scripts/postgres/speeddial-create.sql
    trunk/scripts/postgres/uri_db-create.sql
    trunk/scripts/postgres/userblacklist-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.


From noreply at sourceforge.net  Sat Feb  7 17:51:23 2009
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat, 07 Feb 2009 16:51:23 +0000
Subject: [OpenSIPS-Devel] [ opensips-Patches-2577793 ] Avoid usage of
	unsupported grep option in db script
Message-ID: <E1LVqOp-0003cw-B3@d55xhf1.ch3.sourceforge.com>

Patches item #2577793, was opened at 2009-02-07 11:51
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086412&aid=2577793&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: Sergio Gutierrez (saguti)
Assigned to: Nobody/Anonymous (nobody)
Summary: Avoid usage of unsupported grep option in db script

Initial Comment:
At charset_test() in opensipsdbctl.mysql script. grep is called with an option which is not supported by standard grep in Solaris.
This patch proposes a different approach for that case; it defines a variable which counts how many times user has failed in passing a supported charset; after 3 tries, script exits with error code of 1.

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

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


From saguti at gmail.com  Sat Feb  7 18:01:25 2009
From: saguti at gmail.com (Sergio Gutierrez)
Date: Sat, 07 Feb 2009 17:01:25 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[5261]
	trunk/scripts/opensipsctlrc
Message-ID: <E1LVqYX-0006Jr-TT@c3vjzd1.ch3.sourceforge.com>

Revision: 5261
          http://opensips.svn.sourceforge.net/opensips/?rev=5261&view=rev
Author:   saguti
Date:     2009-02-07 17:01:25 +0000 (Sat, 07 Feb 2009)

Log Message:
-----------
Changed default value of GREP to grep; current value (egrep) causes errors because of unsupported options in Solaris when used in mysql scripts.

Modified Paths:
--------------
    trunk/scripts/opensipsctlrc


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


From saguti at gmail.com  Sat Feb  7 23:49:45 2009
From: saguti at gmail.com (Sergio Gutierrez)
Date: Sat, 07 Feb 2009 22:49:45 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[5262]
	trunk/modules/db_mysql/val.c
Message-ID: <E1LVvzd-0004S4-84@bj8yhf1.ch3.sourceforge.com>

Revision: 5262
          http://opensips.svn.sourceforge.net/opensips/?rev=5262&view=rev
Author:   saguti
Date:     2009-02-07 22:49:45 +0000 (Sat, 07 Feb 2009)

Log Message:
-----------
- Missed correction for tm_mon member of tm struct returned by locatime(3). tm_mon contains number of months of year from January, in range 0 to 11.

Modified Paths:
--------------
    trunk/modules/db_mysql/val.c


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


From saguti at gmail.com  Sun Feb  8 00:32:33 2009
From: saguti at gmail.com (Sergio Gutierrez)
Date: Sat, 07 Feb 2009 23:32:33 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[5263] trunk/modules
Message-ID: <E1LVwf3-0005iu-Nk@d5vjzd1.ch3.sourceforge.com>

Revision: 5263
          http://opensips.svn.sourceforge.net/opensips/?rev=5263&view=rev
Author:   saguti
Date:     2009-02-07 23:32:33 +0000 (Sat, 07 Feb 2009)

Log Message:
-----------
- New module which offers to OpenSIPS a functionality like Centrex by allowing to have closed dialing within groups of users defined by administrator.

Added Paths:
-----------
    trunk/modules/closeddial/
    trunk/modules/closeddial/Makefile
    trunk/modules/closeddial/README
    trunk/modules/closeddial/cdlookup.c
    trunk/modules/closeddial/cdlookup.h
    trunk/modules/closeddial/closeddial.c
    trunk/modules/closeddial/closeddial.h


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


From saguti at gmail.com  Sun Feb  8 00:35:07 2009
From: saguti at gmail.com (Sergio Gutierrez)
Date: Sat, 07 Feb 2009 23:35:07 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[5264]
	trunk/modules/closeddial/doc/
Message-ID: <E1LVwhX-0005nT-Ag@d5vjzd1.ch3.sourceforge.com>

Revision: 5264
          http://opensips.svn.sourceforge.net/opensips/?rev=5264&view=rev
Author:   saguti
Date:     2009-02-07 23:35:07 +0000 (Sat, 07 Feb 2009)

Log Message:
-----------
- New module wich offers to OpenSIPS a functionality like Centrex.

Added Paths:
-----------
    trunk/modules/closeddial/doc/


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


From saguti at gmail.com  Sun Feb  8 00:36:24 2009
From: saguti at gmail.com (Sergio Gutierrez)
Date: Sat, 07 Feb 2009 23:36:24 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[5265]
	trunk/modules/closeddial/doc
Message-ID: <E1LVwim-0005py-Af@d5vjzd1.ch3.sourceforge.com>

Revision: 5265
          http://opensips.svn.sourceforge.net/opensips/?rev=5265&view=rev
Author:   saguti
Date:     2009-02-07 23:36:24 +0000 (Sat, 07 Feb 2009)

Log Message:
-----------
- New module which offers to OpenSIPS a functionality like Centrex.

Added Paths:
-----------
    trunk/modules/closeddial/doc/closeddial.xml
    trunk/modules/closeddial/doc/closeddial_admin.xml


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


From saguti at gmail.com  Sun Feb  8 00:49:03 2009
From: saguti at gmail.com (Sergio Gutierrez)
Date: Sat, 07 Feb 2009 23:49:03 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[5266] trunk
Message-ID: <E1LVwv1-0006FL-TK@d5vjzd1.ch3.sourceforge.com>

Revision: 5266
          http://opensips.svn.sourceforge.net/opensips/?rev=5266&view=rev
Author:   saguti
Date:     2009-02-07 23:49:03 +0000 (Sat, 07 Feb 2009)

Log Message:
-----------
- Database schema for table required by closeddial module.

Added Paths:
-----------
    trunk/db/schema/closeddial.xml
    trunk/db/schema/opensips-closeddial.xml
    trunk/scripts/mysql/closeddial-create.sql


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


From saguti at gmail.com  Sun Feb  8 00:49:57 2009
From: saguti at gmail.com (Sergio Gutierrez)
Date: Sat, 07 Feb 2009 23:49:57 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[5267] trunk/Makefile
Message-ID: <E1LVwvt-0006Gr-BQ@d5vjzd1.ch3.sourceforge.com>

Revision: 5267
          http://opensips.svn.sourceforge.net/opensips/?rev=5267&view=rev
Author:   saguti
Date:     2009-02-07 23:49:57 +0000 (Sat, 07 Feb 2009)

Log Message:
-----------
- closeddial module added to list of modules excluded by default on compilation.

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


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


From saguti at gmail.com  Sun Feb  8 01:04:19 2009
From: saguti at gmail.com (Sergio Gutierrez)
Date: Sat, 7 Feb 2009 19:04:19 -0500
Subject: [OpenSIPS-Devel] New: Closeddial module
Message-ID: <8a4af3e20902071604h11b0454ib2fa200a0854d07c@mail.gmail.com>

Hello to all developers and users.

I just have commited a new module to OpenSIPS which is called closeddial.

This module is intended to offer a functionality similar to Centrex to
OpenSIPS, allowing to define groups of closed dialing, using abbreviated
codes.

Closeddial uses a database table, where the relationship between users,
their abbreviated dialing codes and their grouping through a particular
attribute is stored.

An example which illustrates the idea behind module:

Supposing that the following is the content of closeddial table on database

User            closeddial_code          group_id           new_uri
135             00                              companyA
sip:123 at proxy1.com <sip%3A123 at proxy1.com>
357             01                              companyA
sip:357 at proxy1.com <sip%3A357 at proxy1.com>
579             02                              companyA
sip:579 at proxy1.com <sip%3A579 at proxy1.com>
024             00                              companyB
sip:024 at proxy1.com <sip%3A024 at proxy1.com>
246             01                              companyB
sip:246 at proxy1.com <sip%3A246 at proxy1.com>
468             02                              companyB
sip:468 at proxy1.com <sip%3A468 at proxy1.com>

Users defined within group companyA can use abbreviated codes to dial to
others users, instead of using full username; their abbreviated codes will
not collide with codes defined for group companyB, because group_id is
determined by using from username, before looking the uri to rewrite.

group_id value can be left to be determined by querying database, or can be
passed from script, in case it be determined from other mechanism (for
example, an avp loaded at register time).

I hope this module be useful in your deployments of opensips.

Feel free to send me any doubts or feedback about module, through users
lists, or directly to my mail.

Best regards.

-- 
Sergio Guti?rrez
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.opensips.org/pipermail/devel/attachments/20090207/37edda6f/attachment.htm 

From saguti at gmail.com  Sun Feb  8 01:15:17 2009
From: saguti at gmail.com (Sergio Gutierrez)
Date: Sun, 08 Feb 2009 00:15:17 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[5268]
	trunk/modules/registrar/doc/registrar_admin.xml
Message-ID: <E1LVxKP-0000FB-B9@bj8yhf1.ch3.sourceforge.com>

Revision: 5268
          http://opensips.svn.sourceforge.net/opensips/?rev=5268&view=rev
Author:   saguti
Date:     2009-02-08 00:15:17 +0000 (Sun, 08 Feb 2009)

Log Message:
-----------
- Error in example. The variable to evaluate return code of previous function is $retcode

Modified Paths:
--------------
    trunk/modules/registrar/doc/registrar_admin.xml


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


From saguti at gmail.com  Sun Feb  8 01:17:25 2009
From: saguti at gmail.com (Sergio Gutierrez)
Date: Sun, 08 Feb 2009 00:17:25 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[5269]
 branches/1.4/modules/registrar/doc/ registrar_admin.xml
Message-ID: <E1LVxMT-0000Jq-Qj@bj8yhf1.ch3.sourceforge.com>

Revision: 5269
          http://opensips.svn.sourceforge.net/opensips/?rev=5269&view=rev
Author:   saguti
Date:     2009-02-08 00:17:25 +0000 (Sun, 08 Feb 2009)

Log Message:
-----------
- Error in example. The variable to evaluate return code of previous function is $retcode

Modified Paths:
--------------
    branches/1.4/modules/registrar/doc/registrar_admin.xml


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


From bogdan at voice-system.ro  Sun Feb  8 15:41:58 2009
From: bogdan at voice-system.ro (Bogdan-Andrei Iancu)
Date: Sun, 08 Feb 2009 14:41:58 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[5270] trunk/mod_fix.h
Message-ID: <E1LWAr8-0004RO-Ss@3kljzd1.ch3.sourceforge.com>

Revision: 5270
          http://opensips.svn.sourceforge.net/opensips/?rev=5270&view=rev
Author:   bogdan_iancu
Date:     2009-02-08 14:41:58 +0000 (Sun, 08 Feb 2009)

Log Message:
-----------
expose fixup_uint() function to external usage

Modified Paths:
--------------
    trunk/mod_fix.h


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


From noreply at sourceforge.net  Sun Feb  8 18:36:48 2009
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun, 08 Feb 2009 17:36:48 +0000
Subject: [OpenSIPS-Devel] [ opensips-Bugs-2580101 ] Inital database create
	fails
Message-ID: <E1LWDaK-0000De-Rw@g45xhf1.ch3.sourceforge.com>

Bugs item #2580101, was opened at 2009-02-08 17:36
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=2580101&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: Norm Brandinger (norm_brandinger)
Assigned to: Nobody/Anonymous (nobody)
Summary: Inital database create fails

Initial Comment:
Using MySQL. 

Command: opensipsdbctl create

Following error is produced:

Creating core table: avpops
Creating core table: auth_db
Creating core table: pdt
Creating core table: dialog
ERROR 1074 (42000) at line 2: Column length too big for column 'caller_route_set' (max = 255); use BLOB or TEXT instead
ERROR: Creating core tables failed!

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

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


From noreply at sourceforge.net  Sun Feb  8 18:37:06 2009
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun, 08 Feb 2009 17:37:06 +0000
Subject: [OpenSIPS-Devel] [ opensips-Bugs-2580101 ] Initial database create
	fails
Message-ID: <E1LWDac-0006dT-1K@155xhf1.ch3.sourceforge.com>

Bugs item #2580101, was opened at 2009-02-08 17:36
Message generated for change (Settings changed) made by norm_brandinger
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=2580101&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: Norm Brandinger (norm_brandinger)
Assigned to: Nobody/Anonymous (nobody)
>Summary: Initial database create fails

Initial Comment:
Using MySQL. 

Command: opensipsdbctl create

Following error is produced:

Creating core table: avpops
Creating core table: auth_db
Creating core table: pdt
Creating core table: dialog
ERROR 1074 (42000) at line 2: Column length too big for column 'caller_route_set' (max = 255); use BLOB or TEXT instead
ERROR: Creating core tables failed!

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

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


From noreply at sourceforge.net  Sun Feb  8 18:40:32 2009
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun, 08 Feb 2009 17:40:32 +0000
Subject: [OpenSIPS-Devel] [ opensips-Bugs-2580101 ] Initial database create
	fails
Message-ID: <E1LWDdw-0006ZX-4A@d55xhf1.ch3.sourceforge.com>

Bugs item #2580101, was opened at 2009-02-08 17:36
Message generated for change (Comment added) made by norm_brandinger
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=2580101&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: Norm Brandinger (norm_brandinger)
Assigned to: Nobody/Anonymous (nobody)
Summary: Initial database create fails

Initial Comment:
Using MySQL. 

Command: opensipsdbctl create

Following error is produced:

Creating core table: avpops
Creating core table: auth_db
Creating core table: pdt
Creating core table: dialog
ERROR 1074 (42000) at line 2: Column length too big for column 'caller_route_set' (max = 255); use BLOB or TEXT instead
ERROR: Creating core tables failed!

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

>Comment By: Norm Brandinger (norm_brandinger)
Date: 2009-02-08 17:40

Message:
siptrace table has a similar problem during creation:

Creating extra table: cpl
Creating extra table: siptrace
ERROR 1074 (42000) at line 2: Column length too big for column 'callid'
(max = 255); use BLOB or TEXT instead
ERROR: Creating extra tables failed!


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

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


From noreply at sourceforge.net  Sun Feb  8 18:55:14 2009
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun, 08 Feb 2009 17:55:14 +0000
Subject: [OpenSIPS-Devel] [ opensips-Bugs-2580101 ] Initial database create
	/ startup fails
Message-ID: <E1LWDsA-0002A2-BC@d45xhf1.ch3.sourceforge.com>

Bugs item #2580101, was opened at 2009-02-08 17:36
Message generated for change (Settings changed) made by norm_brandinger
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=2580101&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: Norm Brandinger (norm_brandinger)
Assigned to: Nobody/Anonymous (nobody)
>Summary: Initial database create / startup  fails

Initial Comment:
Using MySQL. 

Command: opensipsdbctl create

Following error is produced:

Creating core table: avpops
Creating core table: auth_db
Creating core table: pdt
Creating core table: dialog
ERROR 1074 (42000) at line 2: Column length too big for column 'caller_route_set' (max = 255); use BLOB or TEXT instead
ERROR: Creating core tables failed!

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

>Comment By: Norm Brandinger (norm_brandinger)
Date: 2009-02-08 17:55

Message:
The following error is produced on first startup after a fresh DB install:

ERROR:core:db_check_table_version: invalid version 7 for table subscriber
found, expected 6
ERROR:uri_db:mod_init: Invalid table version.

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

Comment By: Norm Brandinger (norm_brandinger)
Date: 2009-02-08 17:40

Message:
siptrace table has a similar problem during creation:

Creating extra table: cpl
Creating extra table: siptrace
ERROR 1074 (42000) at line 2: Column length too big for column 'callid'
(max = 255); use BLOB or TEXT instead
ERROR: Creating extra tables failed!


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

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


From noreply at sourceforge.net  Sun Feb  8 18:57:54 2009
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun, 08 Feb 2009 17:57:54 +0000
Subject: [OpenSIPS-Devel] [ opensips-Bugs-2580101 ] Initial database create
	/ startup fails
Message-ID: <E1LWDuk-0001jI-Qa@g45xhf1.ch3.sourceforge.com>

Bugs item #2580101, was opened at 2009-02-08 17:36
Message generated for change (Comment added) made by norm_brandinger
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=2580101&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: Norm Brandinger (norm_brandinger)
Assigned to: Nobody/Anonymous (nobody)
Summary: Initial database create / startup  fails

Initial Comment:
Using MySQL. 

Command: opensipsdbctl create

Following error is produced:

Creating core table: avpops
Creating core table: auth_db
Creating core table: pdt
Creating core table: dialog
ERROR 1074 (42000) at line 2: Column length too big for column 'caller_route_set' (max = 255); use BLOB or TEXT instead
ERROR: Creating core tables failed!

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

>Comment By: Norm Brandinger (norm_brandinger)
Date: 2009-02-08 17:57

Message:
The table version issue was created from:  authdb_mod.c

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

Comment By: Norm Brandinger (norm_brandinger)
Date: 2009-02-08 17:55

Message:
The following error is produced on first startup after a fresh DB install:

ERROR:core:db_check_table_version: invalid version 7 for table subscriber
found, expected 6
ERROR:uri_db:mod_init: Invalid table version.

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

Comment By: Norm Brandinger (norm_brandinger)
Date: 2009-02-08 17:40

Message:
siptrace table has a similar problem during creation:

Creating extra table: cpl
Creating extra table: siptrace
ERROR 1074 (42000) at line 2: Column length too big for column 'callid'
(max = 255); use BLOB or TEXT instead
ERROR: Creating extra tables failed!


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

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


From bogdan at voice-system.ro  Sun Feb  8 19:07:19 2009
From: bogdan at voice-system.ro (Bogdan-Andrei Iancu)
Date: Sun, 08 Feb 2009 18:07:19 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[5271] trunk/modules/dialog
Message-ID: <E1LWE3r-0003rq-D9@74yxhf1.ch3.sourceforge.com>

Revision: 5271
          http://opensips.svn.sourceforge.net/opensips/?rev=5271&view=rev
Author:   bogdan_iancu
Date:     2009-02-08 18:07:19 +0000 (Sun, 08 Feb 2009)

Log Message:
-----------
- dialog module exports more internal functions via the API

Modified Paths:
--------------
    trunk/modules/dialog/dialog.c
    trunk/modules/dialog/dlg_load.h
    trunk/modules/dialog/dlg_profile.h


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


From bogdan at voice-system.ro  Sun Feb  8 19:10:56 2009
From: bogdan at voice-system.ro (Bogdan-Andrei Iancu)
Date: Sun, 08 Feb 2009 18:10:56 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[5272]
	trunk/modules/uri_db/uridb_mod.c
Message-ID: <E1LWE7M-0003v1-23@74yxhf1.ch3.sourceforge.com>

Revision: 5272
          http://opensips.svn.sourceforge.net/opensips/?rev=5272&view=rev
Author:   bogdan_iancu
Date:     2009-02-08 18:10:55 +0000 (Sun, 08 Feb 2009)

Log Message:
-----------
- parte of DB schema changes - forgot to increase table versions
  Part of the bug report #2580101.

Modified Paths:
--------------
    trunk/modules/uri_db/uridb_mod.c


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


From noreply at sourceforge.net  Sun Feb  8 19:13:16 2009
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun, 08 Feb 2009 18:13:16 +0000
Subject: [OpenSIPS-Devel] [ opensips-Bugs-2580101 ] Initial database create
	/ startup fails
Message-ID: <E1LWE9c-00054f-D2@665xhf1.ch3.sourceforge.com>

Bugs item #2580101, was opened at 2009-02-08 17:36
Message generated for change (Comment added) made by norm_brandinger
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=2580101&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: Norm Brandinger (norm_brandinger)
Assigned to: Nobody/Anonymous (nobody)
Summary: Initial database create / startup  fails

Initial Comment:
Using MySQL. 

Command: opensipsdbctl create

Following error is produced:

Creating core table: avpops
Creating core table: auth_db
Creating core table: pdt
Creating core table: dialog
ERROR 1074 (42000) at line 2: Column length too big for column 'caller_route_set' (max = 255); use BLOB or TEXT instead
ERROR: Creating core tables failed!

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

>Comment By: Norm Brandinger (norm_brandinger)
Date: 2009-02-08 18:13

Message:
It looks like another module is referring to VERSION 6 of the subscriber
table: uridb_mod.c

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

Comment By: Norm Brandinger (norm_brandinger)
Date: 2009-02-08 17:57

Message:
The table version issue was created from:  authdb_mod.c

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

Comment By: Norm Brandinger (norm_brandinger)
Date: 2009-02-08 17:55

Message:
The following error is produced on first startup after a fresh DB install:

ERROR:core:db_check_table_version: invalid version 7 for table subscriber
found, expected 6
ERROR:uri_db:mod_init: Invalid table version.

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

Comment By: Norm Brandinger (norm_brandinger)
Date: 2009-02-08 17:40

Message:
siptrace table has a similar problem during creation:

Creating extra table: cpl
Creating extra table: siptrace
ERROR 1074 (42000) at line 2: Column length too big for column 'callid'
(max = 255); use BLOB or TEXT instead
ERROR: Creating extra tables failed!


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

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


From bogdan at voice-system.ro  Sun Feb  8 19:22:17 2009
From: bogdan at voice-system.ro (Bogdan-Andrei Iancu)
Date: Sun, 08 Feb 2009 18:22:17 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[5273]
	trunk/doc/dbschema/xsl/mysql.xsl
Message-ID: <E1LWEIL-0004sx-Bu@74yxhf1.ch3.sourceforge.com>

Revision: 5273
          http://opensips.svn.sourceforge.net/opensips/?rev=5273&view=rev
Author:   bogdan_iancu
Date:     2009-02-08 18:22:17 +0000 (Sun, 08 Feb 2009)

Log Message:
-----------
- forgot commit - the new generator form for the mysql tables

Modified Paths:
--------------
    trunk/doc/dbschema/xsl/mysql.xsl


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


From bogdan at voice-system.ro  Sun Feb  8 19:24:01 2009
From: bogdan at voice-system.ro (Bogdan-Andrei Iancu)
Date: Sun, 08 Feb 2009 18:24:01 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[5274]
	trunk/modules/auth_db/authdb_mod.c
Message-ID: <E1LWEK1-0004ul-8Z@74yxhf1.ch3.sourceforge.com>

Revision: 5274
          http://opensips.svn.sourceforge.net/opensips/?rev=5274&view=rev
Author:   bogdan_iancu
Date:     2009-02-08 18:24:01 +0000 (Sun, 08 Feb 2009)

Log Message:
-----------
- forgot to increase table version (subscriber) in auth module.
  Partial fix for bug #2580101.
  Credits go to Norman Brandinger

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


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


From bogdan at voice-system.ro  Sun Feb  8 19:41:01 2009
From: bogdan at voice-system.ro (Bogdan-Andrei Iancu)
Date: Sun, 08 Feb 2009 18:41:01 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[5275] trunk/modules/dialog
Message-ID: <E1LWEaT-0005yr-BO@74yxhf1.ch3.sourceforge.com>

Revision: 5275
          http://opensips.svn.sourceforge.net/opensips/?rev=5275&view=rev
Author:   bogdan_iancu
Date:     2009-02-08 18:41:01 +0000 (Sun, 08 Feb 2009)

Log Message:
-----------
- one more function (search_profile) added to the internal API

Modified Paths:
--------------
    trunk/modules/dialog/dialog.c
    trunk/modules/dialog/dlg_load.h
    trunk/modules/dialog/dlg_profile.h


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


From noreply at sourceforge.net  Mon Feb  9 05:50:14 2009
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 09 Feb 2009 04:50:14 +0000
Subject: [OpenSIPS-Devel] [ opensips-Patches-2580677 ] Dynamic loading of
	proxies for nathelper module
Message-ID: <E1LWO62-00052N-34@b55xhf1.ch3.sourceforge.com>

Patches item #2580677, was opened at 2009-02-08 23:50
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086412&aid=2580677&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: Sergio Gutierrez (saguti)
Assigned to: Nobody/Anonymous (nobody)
Summary: Dynamic loading of proxies for nathelper module

Initial Comment:
The attached patch allows to load dynamically the list of proxies used by nathelper module.
It also defines a command which allows to reload the list through management interface.
Dynamic loading of proxies is compatible through loading via configuration file; it is enabled by providing a database url as module parameter.

The table with proxies information has 4 columns: type (unix, udp, udp6), address (ip for udp, udp6; filename for unix), port (N/A for unix), and set id.

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

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


From noreply at sourceforge.net  Mon Feb  9 07:10:15 2009
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 09 Feb 2009 06:10:15 +0000
Subject: [OpenSIPS-Devel] [ opensips-Patches-2580715 ] Changes mysql store
	engine for location
Message-ID: <E1LWPLT-0005SK-HO@565xhf1.ch3.sourceforge.com>

Patches item #2580715, was opened at 2009-02-09 01:10
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086412&aid=2580715&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: Sergio Gutierrez (saguti)
Assigned to: Nobody/Anonymous (nobody)
Summary: Changes mysql store engine for location

Initial Comment:

The default  value of store engine for location table is not convenient for a big number of users, as MyISAM locks whole table when executing updates; It would be more convenient to use InnoDB for this table, as it uses locking at row level; InnoDB is by default avaiable in MySQL 5.0.X, and it can be enabled at compilation time in MySQL 5.1.X.

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

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


From brett at nemeroff.com  Sun Feb  8 02:21:55 2009
From: brett at nemeroff.com (Brett Nemeroff)
Date: Sat, 7 Feb 2009 19:21:55 -0600
Subject: [OpenSIPS-Devel] [OpenSIPS-Users] New: Closeddial module
In-Reply-To: <8a4af3e20902071604h11b0454ib2fa200a0854d07c@mail.gmail.com>
References: <8a4af3e20902071604h11b0454ib2fa200a0854d07c@mail.gmail.com>
Message-ID: <4f67656a0902071721i24f32778h305a5376186e7ff5@mail.gmail.com>

This is interesting, but I wonder...
Seems like it would be more useful if this was integrated also into the
register function so that dynamic clients can be grouped.

Said another way, seems like "new_uri" doesn't really make sense. It should
point either a new_uri or to an already registered contact. If it was
integrated into register, you'd put the user into a group when they
register, then the lookup function would also need to pass the group.

Maybe I'm thinking about this wrong.. Good idea tho. :)
-Brett


On Sat, Feb 7, 2009 at 6:04 PM, Sergio Gutierrez <saguti at gmail.com> wrote:

> Hello to all developers and users.
>
> I just have commited a new module to OpenSIPS which is called closeddial.
>
> This module is intended to offer a functionality similar to Centrex to
> OpenSIPS, allowing to define groups of closed dialing, using abbreviated
> codes.
>
> Closeddial uses a database table, where the relationship between users,
> their abbreviated dialing codes and their grouping through a particular
> attribute is stored.
>
> An example which illustrates the idea behind module:
>
> Supposing that the following is the content of closeddial table on database
>
> User            closeddial_code          group_id           new_uri
> 135             00                              companyA
> sip:123 at proxy1.com <sip%3A123 at proxy1.com>
> 357             01                              companyA
> sip:357 at proxy1.com <sip%3A357 at proxy1.com>
> 579             02                              companyA
> sip:579 at proxy1.com <sip%3A579 at proxy1.com>
> 024             00                              companyB
> sip:024 at proxy1.com <sip%3A024 at proxy1.com>
> 246             01                              companyB
> sip:246 at proxy1.com <sip%3A246 at proxy1.com>
> 468             02                              companyB
> sip:468 at proxy1.com <sip%3A468 at proxy1.com>
>
> Users defined within group companyA can use abbreviated codes to dial to
> others users, instead of using full username; their abbreviated codes will
> not collide with codes defined for group companyB, because group_id is
> determined by using from username, before looking the uri to rewrite.
>
> group_id value can be left to be determined by querying database, or can be
> passed from script, in case it be determined from other mechanism (for
> example, an avp loaded at register time).
>
> I hope this module be useful in your deployments of opensips.
>
> Feel free to send me any doubts or feedback about module, through users
> lists, or directly to my mail.
>
> Best regards.
>
> --
> Sergio Guti?rrez
>
> _______________________________________________
> Users mailing list
> Users at lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.opensips.org/pipermail/devel/attachments/20090207/d4a5e3e9/attachment.htm 

From noreply at sourceforge.net  Mon Feb  9 12:30:10 2009
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 09 Feb 2009 11:30:10 +0000
Subject: [OpenSIPS-Devel] [ opensips-Bugs-2580101 ] Initial database create
	/ startup fails
Message-ID: <E1LWUL4-0001iF-Q6@565xhf1.ch3.sourceforge.com>

Bugs item #2580101, was opened at 2009-02-08 19:36
Message generated for change (Settings changed) made by bogdan_iancu
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=2580101&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: Accepted
>Priority: 9
Private: No
Submitted By: Norm Brandinger (norm_brandinger)
>Assigned to: Bogdan-Andrei Iancu (bogdan_iancu)
Summary: Initial database create / startup  fails

Initial Comment:
Using MySQL. 

Command: opensipsdbctl create

Following error is produced:

Creating core table: avpops
Creating core table: auth_db
Creating core table: pdt
Creating core table: dialog
ERROR 1074 (42000) at line 2: Column length too big for column 'caller_route_set' (max = 255); use BLOB or TEXT instead
ERROR: Creating core tables failed!

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

Comment By: Norm Brandinger (norm_brandinger)
Date: 2009-02-08 20:13

Message:
It looks like another module is referring to VERSION 6 of the subscriber
table: uridb_mod.c

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

Comment By: Norm Brandinger (norm_brandinger)
Date: 2009-02-08 19:57

Message:
The table version issue was created from:  authdb_mod.c

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

Comment By: Norm Brandinger (norm_brandinger)
Date: 2009-02-08 19:55

Message:
The following error is produced on first startup after a fresh DB install:

ERROR:core:db_check_table_version: invalid version 7 for table subscriber
found, expected 6
ERROR:uri_db:mod_init: Invalid table version.

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

Comment By: Norm Brandinger (norm_brandinger)
Date: 2009-02-08 19:40

Message:
siptrace table has a similar problem during creation:

Creating extra table: cpl
Creating extra table: siptrace
ERROR 1074 (42000) at line 2: Column length too big for column 'callid'
(max = 255); use BLOB or TEXT instead
ERROR: Creating extra tables failed!


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

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


From bogdan at voice-system.ro  Mon Feb  9 12:31:31 2009
From: bogdan at voice-system.ro (Bogdan-Andrei Iancu)
Date: Mon, 09 Feb 2009 11:31:31 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[5276] trunk/db/schema
Message-ID: <E1LWUMN-0004WS-Qs@dn4whf1.ch3.sourceforge.com>

Revision: 5276
          http://opensips.svn.sourceforge.net/opensips/?rev=5276&view=rev
Author:   bogdan_iancu
Date:     2009-02-09 11:31:31 +0000 (Mon, 09 Feb 2009)

Log Message:
-----------
- fixed issues with the DB schema (related to large strings that were defined as TEXT)
  Closes bug #2580101

- added table definition for a new load-balancer module

Modified Paths:
--------------
    trunk/db/schema/dialog.xml
    trunk/db/schema/dr_gateways.xml
    trunk/db/schema/sip_trace.xml

Added Paths:
-----------
    trunk/db/schema/load_balancer.xml
    trunk/db/schema/opensips-load_balancer.xml


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


From bogdan at voice-system.ro  Mon Feb  9 12:34:29 2009
From: bogdan at voice-system.ro (Bogdan-Andrei Iancu)
Date: Mon, 09 Feb 2009 11:34:29 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[5277] trunk/scripts
Message-ID: <E1LWUPF-0006TQ-CE@dn4whf1.ch3.sourceforge.com>

Revision: 5277
          http://opensips.svn.sourceforge.net/opensips/?rev=5277&view=rev
Author:   bogdan_iancu
Date:     2009-02-09 11:34:29 +0000 (Mon, 09 Feb 2009)

Log Message:
-----------
- DB formats regenerated from new DB schema

Modified Paths:
--------------
    trunk/scripts/db_berkeley/opensips/version
    trunk/scripts/dbtext/opensips/version
    trunk/scripts/mysql/closeddial-create.sql
    trunk/scripts/mysql/dialog-create.sql
    trunk/scripts/mysql/drouting-create.sql
    trunk/scripts/mysql/siptrace-create.sql
    trunk/scripts/opensipsdbctl.base
    trunk/scripts/oracle/dialog-create.sql
    trunk/scripts/oracle/drouting-create.sql
    trunk/scripts/oracle/siptrace-create.sql
    trunk/scripts/postgres/dialog-create.sql
    trunk/scripts/postgres/drouting-create.sql
    trunk/scripts/postgres/siptrace-create.sql


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


From noreply at sourceforge.net  Mon Feb  9 12:34:40 2009
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 09 Feb 2009 11:34:40 +0000
Subject: [OpenSIPS-Devel] [ opensips-Bugs-2580101 ] Initial database create
	/ startup fails
Message-ID: <E1LWUPQ-0003LX-Uq@d55xhf1.ch3.sourceforge.com>

Bugs item #2580101, was opened at 2009-02-08 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=2580101&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: 9
Private: No
Submitted By: Norm Brandinger (norm_brandinger)
Assigned to: Bogdan-Andrei Iancu (bogdan_iancu)
Summary: Initial database create / startup  fails

Initial Comment:
Using MySQL. 

Command: opensipsdbctl create

Following error is produced:

Creating core table: avpops
Creating core table: auth_db
Creating core table: pdt
Creating core table: dialog
ERROR 1074 (42000) at line 2: Column length too big for column 'caller_route_set' (max = 255); use BLOB or TEXT instead
ERROR: Creating core tables failed!

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

>Comment By: Bogdan-Andrei Iancu (bogdan_iancu)
Date: 2009-02-09 13:34

Message:
Hi Norm,

Thank you for the report - all the issues should be fixed by now. Please
update and test.

Best regards,
Bogdan

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

Comment By: Norm Brandinger (norm_brandinger)
Date: 2009-02-08 20:13

Message:
It looks like another module is referring to VERSION 6 of the subscriber
table: uridb_mod.c

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

Comment By: Norm Brandinger (norm_brandinger)
Date: 2009-02-08 19:57

Message:
The table version issue was created from:  authdb_mod.c

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

Comment By: Norm Brandinger (norm_brandinger)
Date: 2009-02-08 19:55

Message:
The following error is produced on first startup after a fresh DB install:

ERROR:core:db_check_table_version: invalid version 7 for table subscriber
found, expected 6
ERROR:uri_db:mod_init: Invalid table version.

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

Comment By: Norm Brandinger (norm_brandinger)
Date: 2009-02-08 19:40

Message:
siptrace table has a similar problem during creation:

Creating extra table: cpl
Creating extra table: siptrace
ERROR 1074 (42000) at line 2: Column length too big for column 'callid'
(max = 255); use BLOB or TEXT instead
ERROR: Creating extra tables failed!


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

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


From bogdan at voice-system.ro  Mon Feb  9 12:43:19 2009
From: bogdan at voice-system.ro (Bogdan-Andrei Iancu)
Date: Mon, 09 Feb 2009 11:43:19 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[5278]
	trunk/modules/dialog/dlg_handlers.c
Message-ID: <E1LWUXn-00025h-SK@dn4whf1.ch3.sourceforge.com>

Revision: 5278
          http://opensips.svn.sourceforge.net/opensips/?rev=5278&view=rev
Author:   bogdan_iancu
Date:     2009-02-09 11:43:19 +0000 (Mon, 09 Feb 2009)

Log Message:
-----------
- fixed accessing the RPL structure in dlg_onreply - the reply may be a FAKED_REPLY when the INVITE is replied from the script.
  Closes bug 2573029
  Credits go to vasil dot kolev at attractel dot com

Modified Paths:
--------------
    trunk/modules/dialog/dlg_handlers.c


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


From bogdan at voice-system.ro  Mon Feb  9 12:46:03 2009
From: bogdan at voice-system.ro (Bogdan-Andrei Iancu)
Date: Mon, 09 Feb 2009 11:46:03 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[5279]
	branches/1.4/modules/dialog/dlg_handlers.c
Message-ID: <E1LWUaR-0002wN-0h@dn4whf1.ch3.sourceforge.com>

Revision: 5279
          http://opensips.svn.sourceforge.net/opensips/?rev=5279&view=rev
Author:   bogdan_iancu
Date:     2009-02-09 11:46:02 +0000 (Mon, 09 Feb 2009)

Log Message:
-----------
backport from trunk (rev #5278):
- fixed accessing the RPL structure in dlg_onreply - the reply may be a FAKED_REPLY when the INVITE is replied from the script.
  Closes bug 2573029
  Credits go to vasil dot kolev at attractel dot com

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

Modified Paths:
--------------
    branches/1.4/modules/dialog/dlg_handlers.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 Feb  9 12:46:05 2009
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 09 Feb 2009 11:46:05 +0000
Subject: [OpenSIPS-Devel] [ opensips-Bugs-2573029 ] [trunk/r5254] crash in
	dialog/
Message-ID: <E1LWUaT-0006zB-6X@d45xhf1.ch3.sourceforge.com>

Bugs item #2573029, was opened at 2009-02-06 17:40
Message generated for change (Comment added) made by bogdan_iancu
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=2573029&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: 9
Private: No
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Bogdan-Andrei Iancu (bogdan_iancu)
Summary: [trunk/r5254] crash in dialog/

Initial Comment:
(from vasil.kolev at attractel.com)

Turns out that you can pass rpl == FAKED_REPLY (which is -1) to dlg_onreply(), which will in turn try to dereference it and crash. This fixes it for me, if you're interested, I can reproduce the core dump.

This happens when testing presence and related stuff.


--- modules/dialog/dlg_handlers.c	(revision 5254)
+++ modules/dialog/dlg_handlers.c	(working copy)
@@ -288,24 +288,29 @@
 		LM_DBG("dialog %p confirmed\n",dlg);
 
 		/* get to tag*/
-		if ( !rpl->to && ((parse_headers(rpl, HDR_TO_F,0)<0) || !rpl->to) ) {
-			LM_ERR("bad reply or missing TO hdr :-/\n");
-			tag.s = 0;
-			tag.len = 0;
-		} else {
-			tag = get_to(rpl)->tag_value;
-			if (tag.s==0 || tag.len==0) {
-				LM_ERR("missing TAG param in TO hdr :-/\n");
+		if ( rpl != FAKED_REPLY){
+			if ( !rpl->to && ((parse_headers(rpl, HDR_TO_F,0)<0) || !rpl->to) ) {
+				LM_ERR("bad reply or missing TO hdr :-/\n");
 				tag.s = 0;
 				tag.len = 0;
+			} else {
+				tag = get_to(rpl)->tag_value;
+				if (tag.s==0 || tag.len==0) {
+					LM_ERR("missing TAG param in TO hdr :-/\n");
+					tag.s = 0;
+					tag.len = 0;
+				}
 			}
+			/* save callee's tag, cseq, contact and record route*/
+			if (populate_leg_info( dlg, rpl, t, DLG_CALLEE_LEG, &tag) !=0) {
+				LM_ERR("could not add further info to the dialog\n");
+			}
+		} else {
+			LM_DBG("FAKED_REPLY detected\n");
+			tag.s = 0;
+			tag.len = 0;
 		}
 
-		/* save callee's tag, cseq, contact and record route*/
-		if (populate_leg_info( dlg, rpl, t, DLG_CALLEE_LEG, &tag) !=0) {
-			LM_ERR("could not add further info to the dialog\n");
-		}
-
 		/* set start time */
 		dlg->start_ts = (unsigned int)(time(0));
 


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

>Comment By: Bogdan-Andrei Iancu (bogdan_iancu)
Date: 2009-02-09 13:46

Message:
Hi Vasil,

That is totally correct - thank you for the report and fix. I already
applied it on SVN (1.4 and 1.5/head).

Best regards,
Bogdan

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

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


From bogdan at voice-system.ro  Mon Feb  9 12:46:23 2009
From: bogdan at voice-system.ro (Bogdan-Andrei Iancu)
Date: Mon, 09 Feb 2009 11:46:23 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[5280] trunk/Makefile.defs
Message-ID: <E1LWUal-00032r-1j@dn4whf1.ch3.sourceforge.com>

Revision: 5280
          http://opensips.svn.sourceforge.net/opensips/?rev=5280&view=rev
Author:   bogdan_iancu
Date:     2009-02-09 11:46:22 +0000 (Mon, 09 Feb 2009)

Log Message:
-----------
- increased the dev version

Modified Paths:
--------------
    trunk/Makefile.defs


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


From noreply at sourceforge.net  Mon Feb  9 12:48:20 2009
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 09 Feb 2009 11:48:20 +0000
Subject: [OpenSIPS-Devel] [ opensips-Bugs-2187147 ] Core memory allocation
	failure.
Message-ID: <E1LWUce-0004Ex-6A@1bkjzd1.ch3.sourceforge.com>

Bugs item #2187147, was opened at 2008-10-22 19:20
Message generated for change (Comment added) made by bogdan_iancu
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=2187147&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.4.x
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Alexandre Ferreira (areisferreira)
Assigned to: Bogdan-Andrei Iancu (bogdan_iancu)
Summary: Core memory allocation failure.

Initial Comment:
After some time operating the server Opensips stop the relay of messages and log the following errors:

Oct 16 17:02:52 opensips-1.4.2[22197]: ERROR:core:do_action: memory allocation failure

Oct 16 17:02:52 opensips-1.4.2[22197]: ERROR:core:do_action: memory allocation failure

Oct 16 17:02:56 opensips-1.4.2[22197]: ERROR:core:build_res_buf_from_sip_res: out of pkg mem

Oct 16 17:02:56 opensips-1.4.2[22197]: ERROR:tm:relay_reply: no mem for outbound reply buffer

Oct 22 09:04:20 opensips-1.4.2[22197]: ERROR:core:build_res_buf_from_sip_req: out of pkg memory  ; needs 296

Oct 22 09:04:20 opensips-1.4.2[22197]: ERROR:sl:sl_send_reply_helper: response building failed

Oct 22 09:04:20 opensips-1.4.2[22197]: ERROR:core:do_action: memory allocation failure

Oct 22 09:04:20 opensips-1.4.2[22197]: ERROR:core:do_action: memory allocation failure

Oct 22 09:04:20 opensips-1.4.2[22197]: ERROR:core:build_res_buf_from_sip_req: out of pkg memory  ; needs 361

Oct 22 09:04:20 opensips-1.4.2[22197]: ERROR:sl:sl_send_reply_helper: response building failed

Oct 22 09:04:20 opensips-1.4.2[22203]: ERROR:core:build_res_buf_from_sip_req: out of pkg memory  ; needs 296

Oct 22 09:04:20 opensips-1.4.2[22203]: ERROR:sl:sl_send_reply_helper: response building failed


Regards,
Alexandre Ferreira.

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

>Comment By: Bogdan-Andrei Iancu (bogdan_iancu)
Date: 2009-02-09 13:48

Message:
Last call...any updates on this Alexandre?

If not, I will close this bug.

Regards,
Bogdan

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

Comment By: Bogdan-Andrei Iancu (bogdan_iancu)
Date: 2008-12-05 11:59

Message:
Hi Alexandre,

any news on this?

Regards,
Bogdan

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

Comment By: Bogdan-Andrei Iancu (bogdan_iancu)
Date: 2008-10-23 10:39

Message:
Hi,

Have you tried the following :
   http://www.opensips.org/index.php?n=Resources.DocsTsMem

Regards,
Bogdan

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

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


From bogdan at voice-system.ro  Mon Feb  9 13:12:03 2009
From: bogdan at voice-system.ro (Bogdan-Andrei Iancu)
Date: Mon, 09 Feb 2009 12:12:03 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[5281] trunk/scripts
Message-ID: <E1LWUzb-00072v-68@dn4whf1.ch3.sourceforge.com>

Revision: 5281
          http://opensips.svn.sourceforge.net/opensips/?rev=5281&view=rev
Author:   bogdan_iancu
Date:     2009-02-09 12:12:02 +0000 (Mon, 09 Feb 2009)

Log Message:
-----------
-definition of the load-balancer table uploaded

Added Paths:
-----------
    trunk/scripts/db_berkeley/opensips/load_balancer
    trunk/scripts/dbtext/opensips/load_balancer
    trunk/scripts/mysql/load_balancer-create.sql
    trunk/scripts/oracle/load_balancer-create.sql
    trunk/scripts/postgres/load_balancer-create.sql


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


From bogdan at voice-system.ro  Mon Feb  9 13:20:22 2009
From: bogdan at voice-system.ro (Bogdan-Andrei Iancu)
Date: Mon, 09 Feb 2009 12:20:22 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[5282]
	trunk/modules/avpops/avpops_db.c
Message-ID: <E1LWV7e-0007wp-UC@dn4whf1.ch3.sourceforge.com>

Revision: 5282
          http://opensips.svn.sourceforge.net/opensips/?rev=5282&view=rev
Author:   bogdan_iancu
Date:     2009-02-09 12:20:22 +0000 (Mon, 09 Feb 2009)

Log Message:
-----------
- clode connections only if open

Modified Paths:
--------------
    trunk/modules/avpops/avpops_db.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 Feb  9 15:40:30 2009
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 09 Feb 2009 14:40:30 +0000
Subject: [OpenSIPS-Devel] [ opensips-Bugs-2581741 ] drouting tables
Message-ID: <E1LWXJG-0007kk-PO@d55xhf1.ch3.sourceforge.com>

Bugs item #2581741, was opened at 2009-02-09 14:40
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=2581741&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: Norm Brandinger (norm_brandinger)
Assigned to: Nobody/Anonymous (nobody)
Summary: drouting tables

Initial Comment:
The tables associated with drouting aren't created during the initial database setup.

They can be manually created with a command similar to the following (for MySQL):

mysql -uopensips -popensips opensips < /usr/share/opensips/mysql/drouting-create.sql


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

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


From noreply at sourceforge.net  Mon Feb  9 15:42:23 2009
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 09 Feb 2009 14:42:23 +0000
Subject: [OpenSIPS-Devel] [ opensips-Patches-2581745 ] fix: dialog load
	callback
Message-ID: <E1LWXL5-0005MO-Ax@3bkjzd1.ch3.sourceforge.com>

Patches item #2581745, was opened at 2009-02-09 15:42
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086412&aid=2581745&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: Hugues Mitonneau (hmitonneau)
Assigned to: Nobody/Anonymous (nobody)
Summary: fix: dialog load callback

Initial Comment:
When the dialog module is initialized, the load callback list is not properly marked as destroyed. So when a module register itself as a load callback, this one is not 'run on the spot'.

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

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


From noreply at sourceforge.net  Mon Feb  9 15:57:51 2009
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 09 Feb 2009 14:57:51 +0000
Subject: [OpenSIPS-Devel] [ opensips-Patches-2581791 ] DR_RELOAD update
Message-ID: <E1LWXa3-0003nS-Vu@b55xhf1.ch3.sourceforge.com>

Patches item #2581791, was opened at 2009-02-09 14:57
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086412&aid=2581791&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: Norm Brandinger (norm_brandinger)
Assigned to: Nobody/Anonymous (nobody)
Summary: DR_RELOAD update

Initial Comment:
DR_RELOAD appears to be the only UPPERCASE command.  The attached patch changes it to be consistent with the rest of the commands.

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

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


From noreply at sourceforge.net  Mon Feb  9 16:46:04 2009
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 09 Feb 2009 15:46:04 +0000
Subject: [OpenSIPS-Devel] [ opensips-Bugs-2166305 ] mi_fifo: opensips_fifo
	removed by 'opensips -c'
Message-ID: <E1LWYKi-0003bs-Bi@155xhf1.ch3.sourceforge.com>

Bugs item #2166305, was opened at 2008-10-14 11:20
Message generated for change (Comment added) made by osas
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=2166305&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.4.x
Status: Open
Resolution: Fixed
Priority: 9
Private: No
Submitted By: Ovidiu Sas (osas)
Assigned to: Bogdan-Andrei Iancu (bogdan_iancu)
Summary: mi_fifo: opensips_fifo removed by 'opensips -c'

Initial Comment:
If opensips is up and running and at the same time 'opensips -c' is run in order to check a new config, if errors are detected in the new config, the opensisps_fifo file is removed.

Note: The error in the config must be detected after the mi_fifo module was loaded successfully.

Note: The mi_datagram may exposed the same issue (if run in unix file socket mode).


Regards,
Ovidiu Sas

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

>Comment By: Ovidiu Sas (osas)
Date: 2009-02-09 10:46

Message:
tested ok, ready for backporting.

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

Comment By: Bogdan-Andrei Iancu (bogdan_iancu)
Date: 2009-02-02 07:51

Message:
Hi Ovidiu,

A fix is available on SVN trunk - please test and if ok, I will do the
backport.

Thanks and regards,
Bogdan

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

Comment By: Bogdan-Andrei Iancu (bogdan_iancu)
Date: 2008-10-15 03:44

Message:
Hi Ovidiu,

I agree with you - cfg file checking should not affect the existing
resources.

Regards,
Bogdan

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

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


From osas at voipembedded.com  Mon Feb  9 17:25:33 2009
From: osas at voipembedded.com (Ovidiu Sas)
Date: Mon, 09 Feb 2009 16:25:33 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[5283]
	trunk/modules/localcache/
Message-ID: <E1LWYwv-0004Fc-Qp@3kljzd1.ch3.sourceforge.com>

Revision: 5283
          http://opensips.svn.sourceforge.net/opensips/?rev=5283&view=rev
Author:   osas
Date:     2009-02-09 16:25:33 +0000 (Mon, 09 Feb 2009)

Log Message:
-----------
set svn properties

Property Changed:
----------------
    trunk/modules/localcache/


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


From bogdan at voice-system.ro  Mon Feb  9 17:29:00 2009
From: bogdan at voice-system.ro (Bogdan-Andrei Iancu)
Date: Mon, 09 Feb 2009 16:29:00 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[5284] branches/1.4/main.c
Message-ID: <E1LWZ0G-0008Lr-F4@dn4whf1.ch3.sourceforge.com>

Revision: 5284
          http://opensips.svn.sourceforge.net/opensips/?rev=5284&view=rev
Author:   bogdan_iancu
Date:     2009-02-09 16:28:58 +0000 (Mon, 09 Feb 2009)

Log Message:
-----------
backport from trunk (rev #5240)
- do not destroy modules if not initialized - module resorces may get lost (fifo files, sockets, etc). 
Side efect of this bug: If opensips is up and running and at the same time 'opensips -c' is run in order to check a new config, if errors are detected in the new config, the opensisps_fifo file is removed.

Closes bug 2166305.

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

Modified Paths:
--------------
    branches/1.4/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  Mon Feb  9 17:29:15 2009
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 09 Feb 2009 16:29:15 +0000
Subject: [OpenSIPS-Devel] [ opensips-Bugs-2166305 ] mi_fifo: opensips_fifo
	removed by 'opensips -c'
Message-ID: <E1LWZ0V-0001RT-DJ@g45xhf1.ch3.sourceforge.com>

Bugs item #2166305, was opened at 2008-10-14 18:20
Message generated for change (Settings changed) made by bogdan_iancu
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=2166305&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.4.x
>Status: Closed
Resolution: Fixed
Priority: 9
Private: No
Submitted By: Ovidiu Sas (osas)
Assigned to: Bogdan-Andrei Iancu (bogdan_iancu)
Summary: mi_fifo: opensips_fifo removed by 'opensips -c'

Initial Comment:
If opensips is up and running and at the same time 'opensips -c' is run in order to check a new config, if errors are detected in the new config, the opensisps_fifo file is removed.

Note: The error in the config must be detected after the mi_fifo module was loaded successfully.

Note: The mi_datagram may exposed the same issue (if run in unix file socket mode).


Regards,
Ovidiu Sas

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

>Comment By: Bogdan-Andrei Iancu (bogdan_iancu)
Date: 2009-02-09 18:29

Message:
OK, done!

Thanks,
Bogdan

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

Comment By: Ovidiu Sas (osas)
Date: 2009-02-09 17:46

Message:
tested ok, ready for backporting.

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

Comment By: Bogdan-Andrei Iancu (bogdan_iancu)
Date: 2009-02-02 14:51

Message:
Hi Ovidiu,

A fix is available on SVN trunk - please test and if ok, I will do the
backport.

Thanks and regards,
Bogdan

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

Comment By: Bogdan-Andrei Iancu (bogdan_iancu)
Date: 2008-10-15 10:44

Message:
Hi Ovidiu,

I agree with you - cfg file checking should not affect the existing
resources.

Regards,
Bogdan

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

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


From noreply at sourceforge.net  Mon Feb  9 18:14:00 2009
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 09 Feb 2009 17:14:00 +0000
Subject: [OpenSIPS-Devel] [ opensips-Bugs-2581741 ] drouting tables
Message-ID: <E1LWZho-0006w7-GS@h45xhf1.ch3.sourceforge.com>

Bugs item #2581741, was opened at 2009-02-09 16:40
Message generated for change (Settings changed) made by bogdan_iancu
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=2581741&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: Norm Brandinger (norm_brandinger)
>Assigned to: Bogdan-Andrei Iancu (bogdan_iancu)
Summary: drouting tables

Initial Comment:
The tables associated with drouting aren't created during the initial database setup.

They can be manually created with a command similar to the following (for MySQL):

mysql -uopensips -popensips opensips < /usr/share/opensips/mysql/drouting-create.sql


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

>Comment By: Bogdan-Andrei Iancu (bogdan_iancu)
Date: 2009-02-09 19:13

Message:
Fixed.

Thanks and regards,
Bogdan

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

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


From bogdan at voice-system.ro  Mon Feb  9 18:14:02 2009
From: bogdan at voice-system.ro (Bogdan-Andrei Iancu)
Date: Mon, 09 Feb 2009 17:14:02 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[5285]
	trunk/scripts/opensipsdbctl.base
Message-ID: <E1LWZhq-0003rn-6s@c3vjzd1.ch3.sourceforge.com>

Revision: 5285
          http://opensips.svn.sourceforge.net/opensips/?rev=5285&view=rev
Author:   bogdan_iancu
Date:     2009-02-09 17:14:02 +0000 (Mon, 09 Feb 2009)

Log Message:
-----------
- create the Dynamic Routing tables by default

Modified Paths:
--------------
    trunk/scripts/opensipsdbctl.base


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


From bogdan at voice-system.ro  Mon Feb  9 18:21:14 2009
From: bogdan at voice-system.ro (Bogdan-Andrei Iancu)
Date: Mon, 09 Feb 2009 17:21:14 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[5286] trunk/modules/mi_fifo
Message-ID: <E1LWZoo-00044W-Lq@c3vjzd1.ch3.sourceforge.com>

Revision: 5286
          http://opensips.svn.sourceforge.net/opensips/?rev=5286&view=rev
Author:   bogdan_iancu
Date:     2009-02-09 17:21:13 +0000 (Mon, 09 Feb 2009)

Log Message:
-----------
- added implementation for mi_flush - this will accept partial MI reply tees to be flushed to the FIFO stream

Modified Paths:
--------------
    trunk/modules/mi_fifo/fifo_fnc.c
    trunk/modules/mi_fifo/mi_writer.c
    trunk/modules/mi_fifo/mi_writer.h


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


From bogdan at voice-system.ro  Mon Feb  9 18:26:11 2009
From: bogdan at voice-system.ro (Bogdan-Andrei Iancu)
Date: Mon, 09 Feb 2009 17:26:11 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[5287] trunk/modules/mi_xmlrpc
Message-ID: <E1LWZtb-0004l2-Eh@c3vjzd1.ch3.sourceforge.com>

Revision: 5287
          http://opensips.svn.sourceforge.net/opensips/?rev=5287&view=rev
Author:   bogdan_iancu
Date:     2009-02-09 17:26:11 +0000 (Mon, 09 Feb 2009)

Log Message:
-----------
- added implementation for mi_flush - this will accept partial MI reply trees to be flushed to the XMLRPC buffer

Modified Paths:
--------------
    trunk/modules/mi_xmlrpc/xr_server.c
    trunk/modules/mi_xmlrpc/xr_writer.c
    trunk/modules/mi_xmlrpc/xr_writer.h


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


From bogdan at voice-system.ro  Mon Feb  9 18:28:23 2009
From: bogdan at voice-system.ro (Bogdan-Andrei Iancu)
Date: Mon, 09 Feb 2009 17:28:23 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[5288]
	trunk/modules/mi_datagram
Message-ID: <E1LWZvj-0004rs-7q@c3vjzd1.ch3.sourceforge.com>

Revision: 5288
          http://opensips.svn.sourceforge.net/opensips/?rev=5288&view=rev
Author:   bogdan_iancu
Date:     2009-02-09 17:28:23 +0000 (Mon, 09 Feb 2009)

Log Message:
-----------
- added implementation for mi_flush - this will accept partial MI reply trees to be flushed to the datagram buffer

Modified Paths:
--------------
    trunk/modules/mi_datagram/datagram_fnc.c
    trunk/modules/mi_datagram/mi_datagram_writer.c
    trunk/modules/mi_datagram/mi_datagram_writer.h


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


From bogdan at voice-system.ro  Mon Feb  9 18:45:39 2009
From: bogdan at voice-system.ro (Bogdan-Andrei Iancu)
Date: Mon, 09 Feb 2009 17:45:39 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[5289]
	trunk/modules/usrloc/ul_mi.c
Message-ID: <E1LWaCR-0005Wk-KX@c3vjzd1.ch3.sourceforge.com>

Revision: 5289
          http://opensips.svn.sourceforge.net/opensips/?rev=5289&view=rev
Author:   bogdan_iancu
Date:     2009-02-09 17:45:39 +0000 (Mon, 09 Feb 2009)

Log Message:
-----------
- usrloc module is now able to list all AORs+contacts from memory without any memeory size limiations.
- after adding 50 records, flush them to the MI driver to free the used memory

Modified Paths:
--------------
    trunk/modules/usrloc/ul_mi.c


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


From bogdan at voice-system.ro  Mon Feb  9 18:56:22 2009
From: bogdan at voice-system.ro (Bogdan-Andrei Iancu)
Date: Mon, 09 Feb 2009 17:56:22 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[5290] trunk/modules/drouting
Message-ID: <E1LWaMo-00062R-Kt@c3vjzd1.ch3.sourceforge.com>

Revision: 5290
          http://opensips.svn.sourceforge.net/opensips/?rev=5290&view=rev
Author:   bogdan_iancu
Date:     2009-02-09 17:56:22 +0000 (Mon, 09 Feb 2009)

Log Message:
-----------
- MI command DR_RELOAD -> dr_reload ....all mi commands are in lowercase.
  Closes patch 2581791.

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 noreply at sourceforge.net  Mon Feb  9 18:56:22 2009
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 09 Feb 2009 17:56:22 +0000
Subject: [OpenSIPS-Devel] [ opensips-Patches-2581791 ] DR_RELOAD update
Message-ID: <E1LWaMo-0004Vv-DY@d55xhf1.ch3.sourceforge.com>

Patches item #2581791, was opened at 2009-02-09 16:57
Message generated for change (Settings changed) made by bogdan_iancu
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086412&aid=2581791&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: Norm Brandinger (norm_brandinger)
>Assigned to: Bogdan-Andrei Iancu (bogdan_iancu)
Summary: DR_RELOAD update

Initial Comment:
DR_RELOAD appears to be the only UPPERCASE command.  The attached patch changes it to be consistent with the rest of the commands.

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

>Comment By: Bogdan-Andrei Iancu (bogdan_iancu)
Date: 2009-02-09 19:56

Message:
Seams logical! Patch applied.

Thanks and regards,
Bogdan

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

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


From noreply at sourceforge.net  Mon Feb  9 18:57:18 2009
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 09 Feb 2009 17:57:18 +0000
Subject: [OpenSIPS-Devel] [ opensips-Patches-2581791 ] DR_RELOAD update
Message-ID: <E1LWaNi-0003BW-Jb@565xhf1.ch3.sourceforge.com>

Patches item #2581791, was opened at 2009-02-09 16:57
Message generated for change (Settings changed) made by bogdan_iancu
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086412&aid=2581791&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: Norm Brandinger (norm_brandinger)
Assigned to: Bogdan-Andrei Iancu (bogdan_iancu)
Summary: DR_RELOAD update

Initial Comment:
DR_RELOAD appears to be the only UPPERCASE command.  The attached patch changes it to be consistent with the rest of the commands.

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

Comment By: Bogdan-Andrei Iancu (bogdan_iancu)
Date: 2009-02-09 19:56

Message:
Seams logical! Patch applied.

Thanks and regards,
Bogdan

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

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


From bogdan at voice-system.ro  Mon Feb  9 19:01:54 2009
From: bogdan at voice-system.ro (Bogdan-Andrei Iancu)
Date: Mon, 09 Feb 2009 18:01:54 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[5291]
	trunk/modules/dialog/dlg_cb.c
Message-ID: <E1LWaSA-0006Hc-De@c3vjzd1.ch3.sourceforge.com>

Revision: 5291
          http://opensips.svn.sourceforge.net/opensips/?rev=5291&view=rev
Author:   bogdan_iancu
Date:     2009-02-09 18:01:54 +0000 (Mon, 09 Feb 2009)

Log Message:
-----------
When the dialog module is initialized, the load callback list is not properly marked as destroyed. So when a module register itself as a load callback, this one is not 'run on the spot'.

Closes bug #2581745

Modified Paths:
--------------
    trunk/modules/dialog/dlg_cb.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 Feb  9 19:04:12 2009
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 09 Feb 2009 18:04:12 +0000
Subject: [OpenSIPS-Devel] [ opensips-Patches-2581745 ] fix: dialog load
	callback
Message-ID: <E1LWaUO-0007Tg-Ta@d45xhf1.ch3.sourceforge.com>

Patches item #2581745, was opened at 2009-02-09 16:42
Message generated for change (Settings changed) made by bogdan_iancu
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086412&aid=2581745&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: Hugues Mitonneau (hmitonneau)
>Assigned to: Bogdan-Andrei Iancu (bogdan_iancu)
Summary: fix: dialog load callback

Initial Comment:
When the dialog module is initialized, the load callback list is not properly marked as destroyed. So when a module register itself as a load callback, this one is not 'run on the spot'.

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

>Comment By: Bogdan-Andrei Iancu (bogdan_iancu)
Date: 2009-02-09 20:04

Message:
Hi Hugues,

Thank you for the fix . I applied it on trunk and 1.4 branch.

Best regards,
Bogdan

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

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


From bogdan at voice-system.ro  Mon Feb  9 19:04:22 2009
From: bogdan at voice-system.ro (Bogdan-Andrei Iancu)
Date: Mon, 09 Feb 2009 18:04:22 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[5292]
	branches/1.4/modules/dialog/dlg_cb.c
Message-ID: <E1LWaUY-0006OX-N9@c3vjzd1.ch3.sourceforge.com>

Revision: 5292
          http://opensips.svn.sourceforge.net/opensips/?rev=5292&view=rev
Author:   bogdan_iancu
Date:     2009-02-09 18:04:22 +0000 (Mon, 09 Feb 2009)

Log Message:
-----------
backport from trunk (rev #5291):
When the dialog module is initialized, the load callback list is not properly marked as destroyed. So when a module register itself as a load callback, this one is not 'run on the spot'.

Closes bug #2581745

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

Modified Paths:
--------------
    branches/1.4/modules/dialog/dlg_cb.c


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


From bogdan at voice-system.ro  Mon Feb  9 20:03:28 2009
From: bogdan at voice-system.ro (Bogdan-Andrei Iancu)
Date: Mon, 09 Feb 2009 21:03:28 +0200
Subject: [OpenSIPS-Devel] OpenSIPS 1.5.0 - release plan
Message-ID: <49907E00.2040302@voice-system.ro>

Hi,

For preparing 1.5.0 release, the next step is to freeze the SVN and to 
start testing and fixing the code we have.

I suggest to do SVN freeze Monday, next week, on 16th of February, 
starting with 00:00 GMT

What I have still to finish:
    - load-balancer module - to upload
    - identity module - to upload
    - patches (2580677, 2577793,  2538033, 2512634, 2478793, 2171818) - 
see      
                
http://sourceforge.net/tracker/?atid=1086412&group_id=232389&func=browse

If somebody else have some pending work that needs to be finished, 
please let me know and we can accordingly agree on a new SVN freeze date.

Best regards,
Bogdan



From noreply at sourceforge.net  Tue Feb 10 05:37:45 2009
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 10 Feb 2009 04:37:45 +0000
Subject: [OpenSIPS-Devel] [ opensips-Patches-2583676 ] Possible fixing for
	bug 2495521
Message-ID: <E1LWkNV-0001db-1z@665xhf1.ch3.sourceforge.com>

Patches item #2583676, was opened at 2009-02-09 23:37
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086412&aid=2583676&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: Sergio Gutierrez (saguti)
Assigned to: Nobody/Anonymous (nobody)
Summary: Possible fixing for bug 2495521

Initial Comment:
The attached patch is a possible fixing for bug 2495521, related to crashing within seas module.
It also corrects initialization of str structs, by changing to use str_init() function.

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

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


From noreply at sourceforge.net  Tue Feb 10 06:10:42 2009
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 10 Feb 2009 05:10:42 +0000
Subject: [OpenSIPS-Devel] [ opensips-Bugs-2274274 ] seg fault in db_postgres
Message-ID: <E1LWktO-0006DX-AF@d55xhf1.ch3.sourceforge.com>

Bugs item #2274274, was opened at 2008-11-13 00:25
Message generated for change (Comment added) made by saguti
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=2274274&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: Brent (brent_thomson)
Assigned to: Nobody/Anonymous (nobody)
Summary: seg fault in db_postgres

Initial Comment:
Partial output:

*** glibc detected *** opensips: free(): invalid next size (fast): 0x0000000001166c70 ***
======= Backtrace: =========
/lib64/libc.so.6[0x2b92149b8684]
/lib64/libc.so.6(cfree+0x8c)[0x2b92149bbccc]
/usr/lib64/libpq.so.5(PQsendQuery+0x69)[0x2b921642a819]
/usr/lib64/opensips/modules/db_postgres.so[0x2b921620f0df]
opensips(db_do_query+0x335)[0x4b0da1]
/usr/lib64/opensips/modules/db_postgres.so(db_postgres_query+0x8a)[0x2b921620fd59]
/usr/lib64/opensips/modules/auth_db.so[0x2b92181ae5f1]
/usr/lib64/opensips/modules/auth_db.so[0x2b92181ae0f1]
/usr/lib64/opensips/modules/auth_db.so(proxy_authorize+0x2a)[0x2b92181adec8]
opensips(do_action+0x24d4)[0x410de0]
opensips(run_action_list+0x32)[0x40e1fa]
opensips[0x44d7aa]
opensips(eval_expr+0xc8)[0x451633]
opensips(eval_expr+0x1ac)[0x451717]
opensips(eval_expr+0x1e0)[0x45174b]
opensips(do_action+0x1caf)[0x4105bb]
opensips(run_action_list+0x32)[0x40e1fa]
opensips(do_action+0x1de0)[0x4106ec]
opensips(run_action_list+0x32)[0x40e1fa]
opensips[0x40e46e]
opensips(do_action+0x103b)[0x40f947]
opensips(run_action_list+0x32)[0x40e1fa]
opensips(do_action+0x1de0)[0x4106ec]
opensips(run_action_list+0x32)[0x40e1fa]
opensips[0x40e46e]
opensips(run_top_route+0x61)[0x40e526]
opensips(receive_msg+0x51f)[0x445da6]
opensips(udp_rcv_loop+0x45c)[0x47af5b]
opensips[0x4219ad]
opensips(main+0x1c74)[0x423ccf]
/lib64/libc.so.6(__libc_start_main+0xf4)[0x2b92149648b4]
opensips[0x40e119]

CentOS 5.2
OpenSIPS: latest from svn (about an hour ago)
PostgreSQL libs: 8.3.4 (built against the same)
DB in writeback mode

Causes OpenSIPS to crash every time within a few minutes of starting. I can reproduce the crash by repeatedly reregistering a hard or soft phone, making a call from a successfully registered device, or anything else that touches the database. Reference build and config is OpenSER 1.2, which does not have the problem.

The core dump is too large to attach so I've posted it here:

http://www.sendspace.com/file/1pv989


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

Comment By: Sergio Gutierrez (saguti)
Date: 2009-02-10 00:10

Message:
Hello Brent.

I was reviewing your report. Please, could you post OpenSIPS log before
Segmentation Fault?

Regards.

Sergio.

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

Comment By: Brent (brent_thomson)
Date: 2008-11-18 13:05

Message:
Is this what you need?

(gdb) bt
#0  0x00002b9e74dc7155 in raise () from /lib64/libc.so.6
#1  0x00002b9e74dc8bf0 in abort () from /lib64/libc.so.6
#2  0x00002b9e74e013db in __libc_message () from /lib64/libc.so.6
#3  0x00002b9e74e08684 in _int_free () from /lib64/libc.so.6
#4  0x00002b9e74e0bccc in free () from /lib64/libc.so.6
#5  0x00002b9e768797e9 in PQclear () from /usr/lib64/libpq.so.5
#6  0x00002b9e7665fbe9 in free_query (_con=0x779fe8) at dbase.c:320
#7  0x00002b9e7666037d in db_postgres_store_result (_con=0x779fe8,
_r=0x7fff368d58b8)
    at dbase.c:475
#8  0x00000000004b0634 in db_do_query ()
#9  0x00002b9e7665fcc9 in db_postgres_query (_h=0x779fe8,
_k=0x7fff368d5830, _op=0x0, 
    _v=0x7fff368d57f0, _c=0x7802e0, _n=1, _nc=2, _o=0x0,
_r=0x7fff368d58b8) at dbase.c:363
#10 0x00002b9e785fd5b1 in get_ha1 (_username=0x780948,
_domain=0x7fff368d58d0, 
    _table=0x7fff368d58c0, _ha1=0x7fff368d58f0 "", res=0x7fff368d58b8) at
authorize.c:101
#11 0x00002b9e785fd0b1 in authorize (_m=0x77f328, _realm=0x779f30,
_table=0x7737a8 "subscriber", 
    _hftype=HDR_AUTHORIZATION_T) at authorize.c:244
#12 0x00002b9e785fd9fd in www_authorize (_m=0x77f328, _realm=0x779f30
"\001", 
    _table=0x7737a8 "subscriber") at authorize.c:287
#13 0x00000000004105f0 in do_action ()
#14 0x000000000040da0a in run_action_list ()
#15 0x000000000044cfba in eval_elem ()
#16 0x0000000000450e43 in eval_expr ()
#17 0x0000000000450f27 in eval_expr ()
#18 0x0000000000450f5b in eval_expr ()
#19 0x000000000040fdcb in do_action ()
#20 0x000000000040da0a in run_action_list ()
#21 0x000000000040dc7e in run_actions ()
#22 0x000000000040f157 in do_action ()
#23 0x000000000040da0a in run_action_list ()
#24 0x000000000044cfba in eval_elem ()
#25 0x0000000000450e43 in eval_expr ()
#26 0x0000000000450f5b in eval_expr ()
#27 0x000000000040fdcb in do_action ()
#28 0x000000000040da0a in run_action_list ()
#29 0x000000000040fefc in do_action ()
#30 0x000000000040da0a in run_action_list ()
#31 0x000000000040dc7e in run_actions ()
#32 0x000000000040dd36 in run_top_route ()
#33 0x00000000004455b6 in receive_msg ()
#34 0x000000000047a76b in udp_rcv_loop ()
#35 0x0000000000421501 in main_loop ()
#36 0x00000000004234df in main ()


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

Comment By: Brent (brent_thomson)
Date: 2008-11-18 12:17

Message:
That backtrace is the output from opensips itself, with debugging set to 9.
I'm not a gdb jedi. Can you give me instructions or point me to what I need
to do to generate what you're asking for? Is it just a matter of running
the binary in the debugger and then grabbing the output when it crashes?

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

Comment By: Sergio Gutierrez (saguti)
Date: 2008-11-17 19:19

Message:
Hello Brent.

Is that backtrace taken with gdb? The syntax does not loke familiar.
In case it does not, could you take the backtrace with gdb?

Regards.

Sergio.

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

Comment By: Nobody/Anonymous (nobody)
Date: 2008-11-17 18:59

Message:
After fiddling with this some more, it appears that I can only reproduce
this consistently if fork=yes in opensips.cfg. If I don't daemonize
opensips (run it bare, rather than through the init script) and let all the
output go to the console, it no longer crashes.

Please let me know if there's any other useful information that I can
provide.

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

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


From anca at opensips.org  Tue Feb 10 12:33:00 2009
From: anca at opensips.org (Anca Vamanu)
Date: Tue, 10 Feb 2009 11:33:00 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[5293] trunk/mi/mi_core.c
Message-ID: <E1LWqrM-00037Y-QP@d5vjzd1.ch3.sourceforge.com>

Revision: 5293
          http://opensips.svn.sourceforge.net/opensips/?rev=5293&view=rev
Author:   anca_vamanu
Date:     2009-02-10 11:33:00 +0000 (Tue, 10 Feb 2009)

Log Message:
-----------
- added MI functions for memcache interface: cache_store, cache_remove and cache_fetch

Modified Paths:
--------------
    trunk/mi/mi_core.c


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


From anca at opensips.org  Tue Feb 10 12:40:06 2009
From: anca at opensips.org (Anca Vamanu)
Date: Tue, 10 Feb 2009 11:40:06 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[5294]
	trunk/modules/localcache/hash.c
Message-ID: <E1LWqyE-0003W1-Sb@d5vjzd1.ch3.sourceforge.com>

Revision: 5294
          http://opensips.svn.sourceforge.net/opensips/?rev=5294&view=rev
Author:   anca_vamanu
Date:     2009-02-10 11:40:06 +0000 (Tue, 10 Feb 2009)

Log Message:
-----------
- added different return values for cache_fetch for cases: value not found and error

Modified Paths:
--------------
    trunk/modules/localcache/hash.c


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


From bogdan at voice-system.ro  Tue Feb 10 12:50:29 2009
From: bogdan at voice-system.ro (Bogdan-Andrei Iancu)
Date: Tue, 10 Feb 2009 11:50:29 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[5295] trunk/modules
Message-ID: <E1LWr8H-0002uQ-0E@3kljzd1.ch3.sourceforge.com>

Revision: 5295
          http://opensips.svn.sourceforge.net/opensips/?rev=5295&view=rev
Author:   bogdan_iancu
Date:     2009-02-10 11:50:28 +0000 (Tue, 10 Feb 2009)

Log Message:
-----------
- new module that provides SIP Identity implementation (see RFC 4474)
  This module was writen and contributed by Alexander Christ (Cologne University of Applied Sciences) almost 2 years go. I took the patch and refurbished it - updated it for OpenSIPS 1.5.0 and reworked the SIP haeader manipulation code (for creading, adding and searching SIP headers).

Added Paths:
-----------
    trunk/modules/identity/
    trunk/modules/identity/Makefile
    trunk/modules/identity/README
    trunk/modules/identity/doc/
    trunk/modules/identity/doc/identity.xml
    trunk/modules/identity/doc/identity_admin.xml
    trunk/modules/identity/identity.c
    trunk/modules/identity/identity.h
    trunk/modules/identity/openssl-license.txt


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


From noreply at sourceforge.net  Tue Feb 10 13:38:05 2009
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 10 Feb 2009 12:38:05 +0000
Subject: [OpenSIPS-Devel] [ opensips-Bugs-2584959 ] Error in sending NOTIFY
	for PUBLISH in RLS mode
Message-ID: <E1LWrsL-0006kG-RW@155xhf1.ch3.sourceforge.com>

Bugs item #2584959, was opened at 2009-02-10 18:08
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=2584959&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: Nathan (rmnathan)
Assigned to: Nobody/Anonymous (nobody)
Summary: Error in sending NOTIFY for PUBLISH in RLS mode

Initial Comment:
Hi
When opensips got publish for the user(say E1_1) which has in two list subscriptions, it is sending notify to one user only.
For example:
UE2_1 list will have 2 entry uri like E1_1,E1_2
UE2_2 list will have 2 entry uri like E1_2,E1_1

S2_1 subscribe to UE2_1
S2_2 subscribe to UE2_2
If E1_1 send publish, opensips sends notify to S2_1 only. But it should send notify to S2_2 too.

Please find the attached pcap file for detailed call flow.

Regards,
rmnathan


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

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


From bogdan at voice-system.ro  Tue Feb 10 13:40:20 2009
From: bogdan at voice-system.ro (Bogdan-Andrei Iancu)
Date: Tue, 10 Feb 2009 12:40:20 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[5296] trunk/Makefile
Message-ID: <E1LWruW-0007uw-KO@c3vjzd1.ch3.sourceforge.com>

Revision: 5296
          http://opensips.svn.sourceforge.net/opensips/?rev=5296&view=rev
Author:   bogdan_iancu
Date:     2009-02-10 12:40:20 +0000 (Tue, 10 Feb 2009)

Log Message:
-----------
- module identity removed from default compiling as it depends on external libs (ssl)

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


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


From noreply at sourceforge.net  Tue Feb 10 14:16:05 2009
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 10 Feb 2009 13:16:05 +0000
Subject: [OpenSIPS-Devel] [ opensips-Patches-2585066 ] new feature: dialog
	on saved callback
Message-ID: <E1LWsT7-0007JD-3z@d55xhf1.ch3.sourceforge.com>

Patches item #2585066, was opened at 2009-02-10 14:16
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086412&aid=2585066&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: Hugues Mitonneau (hmitonneau)
Assigned to: Nobody/Anonymous (nobody)
Summary: new feature: dialog on saved callback

Initial Comment:
The patch add a callback type DLGCB_SAVED. The callback is then called each time the dialog is saved into database. This feature is interesting for modules that need to save additional information into database.
- The module can then benefit all database scheduling from dialog (none/realtime/delayed/shutdone).
- Data saved by dialog and by the module are synchronous.
- The cell->flags can help the callback to know if data needs to be inserted, updated or deleted.

Hugues


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

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


From noreply at sourceforge.net  Tue Feb 10 14:17:37 2009
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 10 Feb 2009 13:17:37 +0000
Subject: [OpenSIPS-Devel] [ opensips-Patches-2585066 ] new feature: dialog
	on saved callback
Message-ID: <E1LWsUb-0000jl-Bd@d45xhf1.ch3.sourceforge.com>

Patches item #2585066, was opened at 2009-02-10 14:16
Message generated for change (Settings changed) made by hmitonneau
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086412&aid=2585066&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: Hugues Mitonneau (hmitonneau)
Assigned to: Nobody/Anonymous (nobody)
Summary: new feature: dialog on saved callback

Initial Comment:
The patch add a callback type DLGCB_SAVED. The callback is then called each time the dialog is saved into database. This feature is interesting for modules that need to save additional information into database.
- The module can then benefit all database scheduling from dialog (none/realtime/delayed/shutdone).
- Data saved by dialog and by the module are synchronous.
- The cell->flags can help the callback to know if data needs to be inserted, updated or deleted.

Hugues


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

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


From noreply at sourceforge.net  Tue Feb 10 14:37:03 2009
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 10 Feb 2009 13:37:03 +0000
Subject: [OpenSIPS-Devel] [ opensips-Patches-2171818 ] dispatcher probe
	asterisk
Message-ID: <E1LWsnP-0004at-4L@h45xhf1.ch3.sourceforge.com>

Patches item #2171818, was opened at 2008-10-16 17:20
Message generated for change (Settings changed) made by bogdan_iancu
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086412&aid=2171818&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: Kevin McAllister (mcallist)
>Assigned to: Anca Vamanu (anca_vamanu)
Summary: dispatcher probe asterisk

Initial Comment:
Asterisk responds with a  404 to Options requests with no user part, which is what the dispatcher probe builds, 404 shows that UA is up and talking sip, so it should be sufficient to pass the probe.  Patch adds 404 status code as a successful result to the probe.

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

>Comment By: Bogdan-Andrei Iancu (bogdan_iancu)
Date: 2009-02-10 15:36

Message:
Anca will implement configurable set of reply codes to be considered as
"successful" probe.

Bogdan

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

Comment By: Olle E. Johansson (oej)
Date: 2008-11-03 14:43

Message:
With proper configuration, Asterisk will answer 200 OK.

Just add the "s" extension in the proper context.

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

Comment By: Kevin McAllister (mcallist)
Date: 2008-11-03 14:36

Message:
Hi Bogdan,

Sounds like a much better approach.  I'll consider spending time
submitting such a patch in the next week if I can find time.  This will be
much easier for me in the long run if it's configurable.

Thanks for taking the time to review and respond.

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

Comment By: Bogdan-Andrei Iancu (bogdan_iancu)
Date: 2008-11-03 13:59

Message:
Hi Kevin,

I do not like this approach with keep adding a build in list to cover all
the possibilities for whatsoever device  - I'm would rather go for a
different approach: default only 200 OK means re-active and you can
configure (module params) a list of custom codes to be considered for
re-activation.
In this way, everybody will be able to set his own codes without polluting
the code itself.

Regards,
Bogdan

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

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


From anca at opensips.org  Tue Feb 10 16:28:56 2009
From: anca at opensips.org (Anca Vamanu)
Date: Tue, 10 Feb 2009 15:28:56 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[5297]
	trunk/modules/dispatcher
Message-ID: <E1LWuXg-0003q6-UU@bj8yhf1.ch3.sourceforge.com>

Revision: 5297
          http://opensips.svn.sourceforge.net/opensips/?rev=5297&view=rev
Author:   anca_vamanu
Date:     2009-02-10 15:28:56 +0000 (Tue, 10 Feb 2009)

Log Message:
-----------
- added 'options_reply_codes' module parameter which allows configuring custom valid reply codes for OPTIONS messages used for pinging
- related to the discution in patch item #2171818

Modified Paths:
--------------
    trunk/modules/dispatcher/README
    trunk/modules/dispatcher/dispatch.c
    trunk/modules/dispatcher/dispatch.h
    trunk/modules/dispatcher/dispatcher.c
    trunk/modules/dispatcher/doc/dispatcher_admin.xml


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


From noreply at sourceforge.net  Tue Feb 10 16:39:09 2009
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 10 Feb 2009 15:39:09 +0000
Subject: [OpenSIPS-Devel] [ opensips-Patches-2171818 ] dispatcher probe
	asterisk
Message-ID: <E1LWuhZ-00028p-C0@d55xhf1.ch3.sourceforge.com>

Patches item #2171818, was opened at 2008-10-16 17:20
Message generated for change (Comment added) made by anca_vamanu
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086412&aid=2171818&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: Kevin McAllister (mcallist)
Assigned to: Anca Vamanu (anca_vamanu)
Summary: dispatcher probe asterisk

Initial Comment:
Asterisk responds with a  404 to Options requests with no user part, which is what the dispatcher probe builds, 404 shows that UA is up and talking sip, so it should be sufficient to pass the probe.  Patch adds 404 status code as a successful result to the probe.

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

>Comment By: Anca Vamanu (anca_vamanu)
Date: 2009-02-10 17:39

Message:
Hi,

I have added a module parameter 'options_reply_codes' that can be set to a
list of valid OPTIONS reply codes separated by comma.
200 is considered valid by default.
Example:
modparam("dispatcher", "options_reply_codes", "403, 501, 404")

regards,
Anca 

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

Comment By: Bogdan-Andrei Iancu (bogdan_iancu)
Date: 2009-02-10 15:36

Message:
Anca will implement configurable set of reply codes to be considered as
"successful" probe.

Bogdan

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

Comment By: Olle E. Johansson (oej)
Date: 2008-11-03 14:43

Message:
With proper configuration, Asterisk will answer 200 OK.

Just add the "s" extension in the proper context.

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

Comment By: Kevin McAllister (mcallist)
Date: 2008-11-03 14:36

Message:
Hi Bogdan,

Sounds like a much better approach.  I'll consider spending time
submitting such a patch in the next week if I can find time.  This will be
much easier for me in the long run if it's configurable.

Thanks for taking the time to review and respond.

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

Comment By: Bogdan-Andrei Iancu (bogdan_iancu)
Date: 2008-11-03 13:59

Message:
Hi Kevin,

I do not like this approach with keep adding a build in list to cover all
the possibilities for whatsoever device  - I'm would rather go for a
different approach: default only 200 OK means re-active and you can
configure (module params) a list of custom codes to be considered for
re-activation.
In this way, everybody will be able to set his own codes without polluting
the code itself.

Regards,
Bogdan

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

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


From bogdan at voice-system.ro  Tue Feb 10 19:12:44 2009
From: bogdan at voice-system.ro (Bogdan-Andrei Iancu)
Date: Tue, 10 Feb 2009 18:12:44 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[5298] trunk/modules
Message-ID: <E1LWx6C-0002N8-5j@c3vjzd1.ch3.sourceforge.com>

Revision: 5298
          http://opensips.svn.sourceforge.net/opensips/?rev=5298&view=rev
Author:   bogdan_iancu
Date:     2009-02-10 18:12:43 +0000 (Tue, 10 Feb 2009)

Log Message:
-----------
- added new module for load balancing

Added Paths:
-----------
    trunk/modules/load_balancer/
    trunk/modules/load_balancer/Makefile
    trunk/modules/load_balancer/lb_data.c
    trunk/modules/load_balancer/lb_data.h
    trunk/modules/load_balancer/lb_db.c
    trunk/modules/load_balancer/lb_db.h
    trunk/modules/load_balancer/lb_parser.c
    trunk/modules/load_balancer/lb_parser.h
    trunk/modules/load_balancer/load_balancer.c


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


From bogdan at voice-system.ro  Tue Feb 10 19:20:01 2009
From: bogdan at voice-system.ro (Bogdan-Andrei Iancu)
Date: Tue, 10 Feb 2009 18:20:01 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[5299]
	trunk/modules/closeddial/doc/closeddial.xml
Message-ID: <E1LWxDF-0002SZ-9W@c3vjzd1.ch3.sourceforge.com>

Revision: 5299
          http://opensips.svn.sourceforge.net/opensips/?rev=5299&view=rev
Author:   bogdan_iancu
Date:     2009-02-10 18:20:01 +0000 (Tue, 10 Feb 2009)

Log Message:
-----------
-fixed sgml for docs

Modified Paths:
--------------
    trunk/modules/closeddial/doc/closeddial.xml


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


From bogdan at voice-system.ro  Tue Feb 10 19:26:02 2009
From: bogdan at voice-system.ro (Bogdan-Andrei Iancu)
Date: Tue, 10 Feb 2009 18:26:02 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[5300]
	trunk/modules/closeddial
Message-ID: <E1LWxJ4-0002lc-OW@c3vjzd1.ch3.sourceforge.com>

Revision: 5300
          http://opensips.svn.sourceforge.net/opensips/?rev=5300&view=rev
Author:   bogdan_iancu
Date:     2009-02-10 18:26:02 +0000 (Tue, 10 Feb 2009)

Log Message:
-----------
- more doc fixing

Modified Paths:
--------------
    trunk/modules/closeddial/README
    trunk/modules/closeddial/doc/closeddial_admin.xml


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


From saguti at gmail.com  Tue Feb 10 19:39:53 2009
From: saguti at gmail.com (Sergio Gutierrez)
Date: Tue, 10 Feb 2009 18:39:53 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[5301]
	trunk/modules/closeddial
Message-ID: <E1LWxWT-0002zY-7M@c3vjzd1.ch3.sourceforge.com>

Revision: 5301
          http://opensips.svn.sourceforge.net/opensips/?rev=5301&view=rev
Author:   saguti
Date:     2009-02-10 18:39:52 +0000 (Tue, 10 Feb 2009)

Log Message:
-----------
- More doc fixes.

Modified Paths:
--------------
    trunk/modules/closeddial/README
    trunk/modules/closeddial/doc/closeddial_admin.xml


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


From iulia at opensips.org  Tue Feb 10 19:41:54 2009
From: iulia at opensips.org (Iulia Bublea)
Date: Tue, 10 Feb 2009 18:41:54 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[5302]
	trunk/scripts/osipsconsole
Message-ID: <E1LWxYQ-00031t-S7@c3vjzd1.ch3.sourceforge.com>

Revision: 5302
          http://opensips.svn.sourceforge.net/opensips/?rev=5302&view=rev
Author:   iulia_bublea
Date:     2009-02-10 18:41:54 +0000 (Tue, 10 Feb 2009)

Log Message:
-----------
Fixed bud reffering to reinit command for database control. Raised by Joan.

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


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


From noreply at sourceforge.net  Tue Feb 10 20:10:27 2009
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 10 Feb 2009 19:10:27 +0000
Subject: [OpenSIPS-Devel] [ opensips-Patches-2171818 ] dispatcher probe
	asterisk
Message-ID: <E1LWy03-0007QP-T6@cdv4jf1.ch3.sourceforge.com>

Patches item #2171818, was opened at 2008-10-16 17:20
Message generated for change (Settings changed) made by bogdan_iancu
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086412&aid=2171818&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: Kevin McAllister (mcallist)
Assigned to: Anca Vamanu (anca_vamanu)
Summary: dispatcher probe asterisk

Initial Comment:
Asterisk responds with a  404 to Options requests with no user part, which is what the dispatcher probe builds, 404 shows that UA is up and talking sip, so it should be sufficient to pass the probe.  Patch adds 404 status code as a successful result to the probe.

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

>Comment By: Bogdan-Andrei Iancu (bogdan_iancu)
Date: 2009-02-10 21:10

Message:
Anca will implement configurable set of reply codes to be considered as
"successful" probe.

Bogdan

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

Comment By: Anca Vamanu (anca_vamanu)
Date: 2009-02-10 17:39

Message:
Hi,

I have added a module parameter 'options_reply_codes' that can be set to a
list of valid OPTIONS reply codes separated by comma.
200 is considered valid by default.
Example:
modparam("dispatcher", "options_reply_codes", "403, 501, 404")

regards,
Anca 

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

Comment By: Bogdan-Andrei Iancu (bogdan_iancu)
Date: 2009-02-10 15:36

Message:
Anca will implement configurable set of reply codes to be considered as
"successful" probe.

Bogdan

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

Comment By: Olle E. Johansson (oej)
Date: 2008-11-03 14:43

Message:
With proper configuration, Asterisk will answer 200 OK.

Just add the "s" extension in the proper context.

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

Comment By: Kevin McAllister (mcallist)
Date: 2008-11-03 14:36

Message:
Hi Bogdan,

Sounds like a much better approach.  I'll consider spending time
submitting such a patch in the next week if I can find time.  This will be
much easier for me in the long run if it's configurable.

Thanks for taking the time to review and respond.

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

Comment By: Bogdan-Andrei Iancu (bogdan_iancu)
Date: 2008-11-03 13:59

Message:
Hi Kevin,

I do not like this approach with keep adding a build in list to cover all
the possibilities for whatsoever device  - I'm would rather go for a
different approach: default only 200 OK means re-active and you can
configure (module params) a list of custom codes to be considered for
re-activation.
In this way, everybody will be able to set his own codes without polluting
the code itself.

Regards,
Bogdan

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

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


From noreply at sourceforge.net  Tue Feb 10 20:15:35 2009
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 10 Feb 2009 19:15:35 +0000
Subject: [OpenSIPS-Devel] [ opensips-Patches-2171818 ] dispatcher probe
	asterisk
Message-ID: <E1LWy51-0007AS-Vm@d55xhf1.ch3.sourceforge.com>

Patches item #2171818, was opened at 2008-10-16 17:20
Message generated for change (Settings changed) made by bogdan_iancu
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086412&aid=2171818&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: Kevin McAllister (mcallist)
Assigned to: Anca Vamanu (anca_vamanu)
Summary: dispatcher probe asterisk

Initial Comment:
Asterisk responds with a  404 to Options requests with no user part, which is what the dispatcher probe builds, 404 shows that UA is up and talking sip, so it should be sufficient to pass the probe.  Patch adds 404 status code as a successful result to the probe.

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

>Comment By: Bogdan-Andrei Iancu (bogdan_iancu)
Date: 2009-02-10 21:15

Message:
Sorry - browser refresh error :D..

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

Comment By: Bogdan-Andrei Iancu (bogdan_iancu)
Date: 2009-02-10 21:10

Message:
Anca will implement configurable set of reply codes to be considered as
"successful" probe.

Bogdan

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

Comment By: Anca Vamanu (anca_vamanu)
Date: 2009-02-10 17:39

Message:
Hi,

I have added a module parameter 'options_reply_codes' that can be set to a
list of valid OPTIONS reply codes separated by comma.
200 is considered valid by default.
Example:
modparam("dispatcher", "options_reply_codes", "403, 501, 404")

regards,
Anca 

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

Comment By: Bogdan-Andrei Iancu (bogdan_iancu)
Date: 2009-02-10 15:36

Message:
Anca will implement configurable set of reply codes to be considered as
"successful" probe.

Bogdan

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

Comment By: Olle E. Johansson (oej)
Date: 2008-11-03 14:43

Message:
With proper configuration, Asterisk will answer 200 OK.

Just add the "s" extension in the proper context.

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

Comment By: Kevin McAllister (mcallist)
Date: 2008-11-03 14:36

Message:
Hi Bogdan,

Sounds like a much better approach.  I'll consider spending time
submitting such a patch in the next week if I can find time.  This will be
much easier for me in the long run if it's configurable.

Thanks for taking the time to review and respond.

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

Comment By: Bogdan-Andrei Iancu (bogdan_iancu)
Date: 2008-11-03 13:59

Message:
Hi Kevin,

I do not like this approach with keep adding a build in list to cover all
the possibilities for whatsoever device  - I'm would rather go for a
different approach: default only 200 OK means re-active and you can
configure (module params) a list of custom codes to be considered for
re-activation.
In this way, everybody will be able to set his own codes without polluting
the code itself.

Regards,
Bogdan

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

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


From bogdan at voice-system.ro  Tue Feb 10 20:22:17 2009
From: bogdan at voice-system.ro (Bogdan-Andrei Iancu)
Date: Tue, 10 Feb 2009 21:22:17 +0200
Subject: [OpenSIPS-Devel] [NEW Module] SIP Identity
Message-ID: <4991D3E9.80507@voice-system.ro>

Hello,


OpenSIPS 1.5.0 has a new module. The "identity" module is an 
implementation of SIP identity as per RFC 4474 
(http://www.ietf.org/rfc/rfc4474.txt).

Abstract (from RFC) :

   The existing security mechanisms in the Session Initiation Protocol
   (SIP) are inadequate for cryptographically assuring the identity of
   the end users that originate SIP requests, especially in an
   interdomain context.  This document defines a mechanism for securely
   identifying originators of SIP messages.  It does so by defining two
   new SIP header fields, Identity, for conveying a signature used for
   validating the identity, and Identity-Info, for conveying a reference
   to the certificate of the signer

This module was written and contributed by Alexander Christ (Cologne 
University of Applied Sciences) almost 2 years go. I took the code and 
refurbished it - updated it for OpenSIPS 1.5.0 and reworked the SIP 
header manipulation code (for creating, adding and searching SIP 
headers), an lot of other thinks.

Unfortunately Alexander was not interested in maintaining this module, 
so I took the job from him, and finally uploaded the module.

Documentation (with examples and scripts) is available on web site : 
http://www.opensips.org/html/docs/modules/devel/identity.html

Please carefully read the "Limitation section" before using this module:
          
http://www.opensips.org/html/docs/modules/devel/identity.html#id228395

The next step (in the future releases) will be to work out these 
limitations.


Regards,
Bogdan



From saguti at gmail.com  Wed Feb 11 03:51:28 2009
From: saguti at gmail.com (Sergio Gutierrez)
Date: Wed, 11 Feb 2009 02:51:28 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[5303]
	trunk/modules/identity/Makefile
Message-ID: <E1LX5CC-0007Lj-8U@bj8yhf1.ch3.sourceforge.com>

Revision: 5303
          http://opensips.svn.sourceforge.net/opensips/?rev=5303&view=rev
Author:   saguti
Date:     2009-02-11 02:51:28 +0000 (Wed, 11 Feb 2009)

Log Message:
-----------
- Additional locations of OpenSSL files in Solaris.

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


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


From saguti at gmail.com  Wed Feb 11 04:39:35 2009
From: saguti at gmail.com (Sergio Gutierrez)
Date: Wed, 11 Feb 2009 03:39:35 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[5304]
	trunk/modules/identity/identity.h
Message-ID: <E1LX5wl-0001Vq-Qb@dn4whf1.ch3.sourceforge.com>

Revision: 5304
          http://opensips.svn.sourceforge.net/opensips/?rev=5304&view=rev
Author:   saguti
Date:     2009-02-11 03:39:35 +0000 (Wed, 11 Feb 2009)

Log Message:
-----------
- Portability issue with fnmatch() flags argument in Solaris.

Modified Paths:
--------------
    trunk/modules/identity/identity.h


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


From saguti at gmail.com  Wed Feb 11 07:05:45 2009
From: saguti at gmail.com (Sergio Gutierrez)
Date: Wed, 11 Feb 2009 06:05:45 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[5305]
	trunk/modules/db_oracle/res.c
Message-ID: <E1LX8ED-0006Ra-Uz@dn4whf1.ch3.sourceforge.com>

Revision: 5305
          http://opensips.svn.sourceforge.net/opensips/?rev=5305&view=rev
Author:   saguti
Date:     2009-02-11 06:05:45 +0000 (Wed, 11 Feb 2009)

Log Message:
-----------
- Fixed undefined goto tag.

Modified Paths:
--------------
    trunk/modules/db_oracle/res.c


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


From jacksonweng at esoft.com.tw  Tue Feb 10 11:15:12 2009
From: jacksonweng at esoft.com.tw (JacksonWeng)
Date: Tue, 10 Feb 2009 18:15:12 +0800
Subject: [OpenSIPS-Devel] SIP-to-XMPP module
Message-ID: <AD9F91C15C93EA46A4101C29DDC50A440C20251EC0@ex2007.esoft.com.tw>

Hi all,

Where can I find any documents or tech paper about the detail of SIP-to-XMPP module?

Jackson
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.opensips.org/pipermail/devel/attachments/20090210/40a414a2/attachment-0001.htm 

From noreply at sourceforge.net  Wed Feb 11 11:18:28 2009
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 11 Feb 2009 10:18:28 +0000
Subject: [OpenSIPS-Devel] [ opensips-Feature Requests-2094884 ] SIP Identity
Message-ID: <E1LXCAm-0006ab-J2@b55xhf1.ch3.sourceforge.com>

Feature Requests item #2094884, was opened at 2008-09-05 15:13
Message generated for change (Comment added) made by bogdan_iancu
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086413&aid=2094884&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
Priority: 5
Private: No
Submitted By: M?sz?ros Mih?ly (rootkiskacsa)
Assigned to: Bogdan-Andrei Iancu (bogdan_iancu)
Summary: SIP Identity 

Initial Comment:
It will be nice if OpenSips can support SIP Identity according RFC 4474.

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

>Comment By: Bogdan-Andrei Iancu (bogdan_iancu)
Date: 2009-02-11 12:18

Message:
Ok - the Identity module is on SVN - please test.

Thanks and regards,
Bogdan

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

Comment By: Bogdan-Andrei Iancu (bogdan_iancu)
Date: 2008-10-03 17:14

Message:
there is already an implementation for it, but never approved because there
where some technical issue - but I could try to work it out. I will dig for
the code and upload it here.

Regards,
Bogdan

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

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


From anca at opensips.org  Wed Feb 11 15:51:50 2009
From: anca at opensips.org (Anca Vamanu)
Date: Wed, 11 Feb 2009 14:51:50 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[5306] trunk/modules
Message-ID: <E1LXGRK-0003Jj-Up@74yxhf1.ch3.sourceforge.com>

Revision: 5306
          http://opensips.svn.sourceforge.net/opensips/?rev=5306&view=rev
Author:   anca_vamanu
Date:     2009-02-11 14:51:50 +0000 (Wed, 11 Feb 2009)

Log Message:
-----------
- fixed readers-writer mechanism: put flag and counter in shared memory

Modified Paths:
--------------
    trunk/modules/drouting/drouting.c
    trunk/modules/load_balancer/load_balancer.c
    trunk/modules/pdt/pdt.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 Feb 12 03:48:49 2009
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 12 Feb 2009 02:48:49 +0000
Subject: [OpenSIPS-Devel] [ opensips-Patches-2591385 ] acc: in-dialog SIP
	req should generate 'Alive' radius req
Message-ID: <E1LXRdB-0005Pk-Ud@1bkjzd1.ch3.sourceforge.com>

Patches item #2591385, was opened at 2009-02-11 21:48
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086412&aid=2591385&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: Ovidiu Sas (osas)
Assigned to: Nobody/Anonymous (nobody)
Summary: acc: in-dialog SIP req should generate 'Alive' radius req

Initial Comment:
The acc module is able to generate only 'Start', 'Stop' and 'Failed' radius requests.  For in-dialog SIP requests (like reINVITEs) a 'Start' radius request is generated.  The correct behavior would be to generate an 'Alive' radius request.
The attached patch is adding the new 'Alive' radius request and generates them based on the existence of the To tag.

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

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


From noreply at sourceforge.net  Thu Feb 12 04:01:34 2009
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 12 Feb 2009 03:01:34 +0000
Subject: [OpenSIPS-Devel] [ opensips-Patches-2591415 ] acc: in-dialog SIP
	req should generate 'Alive' radius req
Message-ID: <E1LXRpW-0004Ti-6U@665xhf1.ch3.sourceforge.com>

Patches item #2591415, was opened at 2009-02-11 22:01
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086412&aid=2591415&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: Ovidiu Sas (osas)
Assigned to: Nobody/Anonymous (nobody)
Summary: acc: in-dialog SIP req should generate 'Alive' radius req

Initial Comment:
The acc module is able to generate only 'Start', 'Stop' and 'Failed' radius requests.  For in-dialog SIP requests (like reINVITEs) a 'Start' radius request is generated.  The correct behavior would be to generate an 'Alive' radius request.
The attached patch is adding the new 'Alive' radius request and generates them based on the existence of the To tag.

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

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


From noreply at sourceforge.net  Thu Feb 12 04:43:16 2009
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 12 Feb 2009 03:43:16 +0000
Subject: [OpenSIPS-Devel] [ opensips-Patches-2591415 ] acc: in-dialog SIP
	req should generate 'Alive' radius req
Message-ID: <E1LXSTs-0000if-Nj@d55xhf1.ch3.sourceforge.com>

Patches item #2591415, was opened at 2009-02-11 22:01
Message generated for change (Settings changed) made by osas
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086412&aid=2591415&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: Deleted
>Resolution: Duplicate
Priority: 5
Private: No
Submitted By: Ovidiu Sas (osas)
Assigned to: Nobody/Anonymous (nobody)
Summary: acc: in-dialog SIP req should generate 'Alive' radius req

Initial Comment:
The acc module is able to generate only 'Start', 'Stop' and 'Failed' radius requests.  For in-dialog SIP requests (like reINVITEs) a 'Start' radius request is generated.  The correct behavior would be to generate an 'Alive' radius request.
The attached patch is adding the new 'Alive' radius request and generates them based on the existence of the To tag.

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

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


From noreply at sourceforge.net  Thu Feb 12 07:31:20 2009
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 12 Feb 2009 06:31:20 +0000
Subject: [OpenSIPS-Devel] [ opensips-Bugs-2591935 ] Error in sending NOTIFY
	for PUBLISH in RLS mode
Message-ID: <E1LXV6W-0006in-KK@g45xhf1.ch3.sourceforge.com>

Bugs item #2591935, was opened at 2009-02-12 12:01
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=2591935&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: Nathan (rmnathan)
Assigned to: Nobody/Anonymous (nobody)
Summary: Error in sending NOTIFY for PUBLISH in RLS mode

Initial Comment:
Hi
When opensips got publish for the user(say E1_1) which has in two list subscriptions, it is sending notify to one user only.
For example:
UE2_1 list will have 2 entry uri like E1_1,E1_2
UE2_2 list will have 2 entry uri like E1_2,E1_1

S2_1 subscribe to UE2_1
S2_2 subscribe to UE2_2
If E1_1 send publish, opensips sends notify to S2_1 only. But it should send notify to S2_2 too.

Please find the attached pcap file for detailed call flow.

Regards,
rmnathan


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

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


From noreply at sourceforge.net  Thu Feb 12 14:48:07 2009
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 12 Feb 2009 13:48:07 +0000
Subject: [OpenSIPS-Devel] [ opensips-Bugs-2593088 ] Crash with db_postgres
	and presence
Message-ID: <E1LXbvD-00016R-KD@155xhf1.ch3.sourceforge.com>

Bugs item #2593088, was opened at 2009-02-12 13:48
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=2593088&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: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: Crash with db_postgres and presence

Initial Comment:
(submitted by vasil.kolev at attractel.com)

The problem is as follows - a query is executed, but for some reason the results from the previous one are read back from the DB driver, which in turn makes opensips to crash as the number of columns is lower and it tries to dereference stuff that doesn't exist.

Appended are the log and the backtrace:


Feb 12 13:42:59 f-ast2 opensips[29504]: DBG:db_postgres:db_postgres_submit_query: 0x8197240 PQsendQuery(select status,reason from watchers where presentity_uri='sip:bbb%40ccc.com at 10.2.30.5' AND watcher_username='aaa%40ccc.com' AND watcher_domain='10.2.30.5' AND event='presence') 
Feb 12 13:42:59 f-ast2 opensips[29504]: DBG:core:db_new_result: allocate 28 bytes for result set at 0x81a0948 
Feb 12 13:42:59 f-ast2 opensips[29504]: DBG:db_postgres:db_postgres_store_result: 0x8197240 PQresultStatus(PGRES_TUPLES_OK) PQgetResult(0x94c0300) 
Feb 12 13:42:59 f-ast2 opensips[29504]: DBG:db_postgres:db_postgres_get_columns: 1 columns returned from the query 
Feb 12 13:42:59 f-ast2 opensips[29504]: DBG:core:db_allocate_columns: allocate 16 bytes for result columns at 0x819ecd0 
Feb 12 13:42:59 f-ast2 opensips[29504]: DBG:db_postgres:db_postgres_get_columns: RES_NAMES(0x819ecd8)[0]=[username] 
Feb 12 13:42:59 f-ast2 opensips[29504]: DBG:db_postgres:db_postgres_get_columns: use DB_STRING result type 
Feb 12 13:42:59 f-ast2 opensips[29504]: DBG:db_postgres:db_postgres_convert_rows: allocate for 1 columns 4 bytes in row buffer at 0x819d5b8 
Feb 12 13:42:59 f-ast2 opensips[29504]: DBG:core:db_allocate_rows: allocate 28 bytes for result rows and values at 0x819f870 
Feb 12 13:42:59 f-ast2 opensips[29504]: DBG:db_postgres:db_postgres_convert_rows: PQgetvalue(0x8197240,0,0)=[aaa at ccc.com] 
Feb 12 13:42:59 f-ast2 opensips[29504]: DBG:db_postgres:db_postgres_convert_rows: allocated 11 bytes for row_buf[0] at 0x819d5c8 
Feb 12 13:42:59 f-ast2 opensips[29504]: DBG:db_postgres:db_postgres_convert_rows: [0][0] Column[username]=[aaa at ccc.com] 
Feb 12 13:42:59 f-ast2 opensips[29504]: DBG:db_postgres:db_postgres_str2val: converting STRING [aaa at ccc.com] 
Feb 12 13:42:59 f-ast2 opensips[29504]: DBG:db_postgres:db_postgres_convert_rows: freeing row buffer at 0x819d5b8 
Feb 12 13:42:59 f-ast2 opensips[29504]: DBG:db_postgres:free_query: PQclear(0x94c0300) result set 
Feb 12 13:42:59 f-ast2 opensips[29507]: DBG:db_postgres:db_postgres_store_result: 0x8197100 PQresultStatus(PGRES_TUPLES_OK) PQgetResult(0x94bb108) 
Feb 12 13:42:59 f-ast2 kernel: [842163.893756] opensips[29504]: segfault at 1 ip b77b98c6 sp bff1ab30 error 4 in presence.so[b7790000+31000]



Core was generated by `opensips'.
Program terminated with signal 11, Segmentation fault.
[New process 29504]
#0  0xb77b98c6 in get_db_subs_auth (subs=0xbff1acf4, found=0xbff1ad94) at subscribe.c:1980
1980			subs->reason.len= strlen(row_vals[1].val.string_val);
(gdb) bt
#0  0xb77b98c6 in get_db_subs_auth (subs=0xbff1acf4, found=0xbff1ad94) at subscribe.c:1980
#1  0xb77ba5cc in handle_subscribe (msg=0x819acb8, str1=0x0, str2=0x0) at subscribe.c:630
#2  0x08055591 in do_action (a=0x8195940, msg=0x819acb8) at action.c:961
#3  0x080541e2 in run_action_list (a=0x8195940, msg=0x819acb8) at action.c:139
#4  0x08056ecd in do_action (a=0x8195fe0, msg=0x819acb8) at action.c:705
#5  0x080541e2 in run_action_list (a=0x8195fe0, msg=0x819acb8) at action.c:139
#6  0x08057529 in do_action (a=0x8196048, msg=0x819acb8) at action.c:711
#7  0x080541e2 in run_action_list (a=0x81953d0, msg=0x819acb8) at action.c:139
#8  0x08056914 in do_action (a=0x8192808, msg=0x819acb8) at action.c:119
#9  0x080541e2 in run_action_list (a=0x8192808, msg=0x819acb8) at action.c:139
#10 0x08056ecd in do_action (a=0x8192870, msg=0x819acb8) at action.c:705
#11 0x080541e2 in run_action_list (a=0x818d6b8, msg=0x819acb8) at action.c:139
#12 0x08057ee1 in run_top_route (a=0x818d6b8, msg=0x819acb8) at action.c:119
#13 0x0809228c in receive_msg (
    buf=0x8164100 "SUBSCRIBE sip:bbb%40ccc.com at 10.2.30.5;transport=UDP SIP/2.0\r\nVia: SIP/2.0/UDP 10.2.2.179:5060;branch=z9hG4bK-d8754z-1c3f735ee1e02d36-1---d8754z-\r\nMax-Forwards: 69\r\nContact: <sip:aaa%40ccc.com at 10.2.2.1"..., len=793, rcv_info=0xbff1bad4) at receive.c:165
#14 0x080cdf4b in udp_rcv_loop () at udp_server.c:449
#15 0x0806c3af in main (argc=1, argv=0xbff1bc64) at main.c:778



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

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


From bogdan at voice-system.ro  Thu Feb 12 14:59:31 2009
From: bogdan at voice-system.ro (Bogdan-Andrei Iancu)
Date: Thu, 12 Feb 2009 13:59:31 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[5307]
	trunk/db/schema/dr_gw_lists.xml
Message-ID: <E1LXc6F-0004qu-9P@d5vjzd1.ch3.sourceforge.com>

Revision: 5307
          http://opensips.svn.sourceforge.net/opensips/?rev=5307&view=rev
Author:   bogdan_iancu
Date:     2009-02-12 13:59:31 +0000 (Thu, 12 Feb 2009)

Log Message:
-----------
- added missing file in DB schema

Added 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 anca at opensips.org  Thu Feb 12 15:18:18 2009
From: anca at opensips.org (Anca Vamanu)
Date: Thu, 12 Feb 2009 14:18:18 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[5308] trunk
Message-ID: <E1LXcOQ-0006lq-Uz@c3vjzd1.ch3.sourceforge.com>

Revision: 5308
          http://opensips.svn.sourceforge.net/opensips/?rev=5308&view=rev
Author:   anca_vamanu
Date:     2009-02-12 14:18:14 +0000 (Thu, 12 Feb 2009)

Log Message:
-----------
- feature added in nathelper module: dynamically loading socket(s) used to connect to RTPProxies from a database table. It introduces an MI command - nh_reload_rttp which replaces the list of rtp proxies with the records in a database table. The records are also read at startup. 
The default name for the database table is nh_sockets and the schema has two important columns: rtpproxy_sock and setid.  
This patch started from the idea in patch#2580677 submitted by Sergio Gutierrez but the implementation was modified considerably. 

Modified Paths:
--------------
    trunk/modules/nathelper/README
    trunk/modules/nathelper/doc/nathelper_admin.xml
    trunk/modules/nathelper/nathelper.c
    trunk/scripts/db_berkeley/opensips/version
    trunk/scripts/dbtext/opensips/version

Added Paths:
-----------
    trunk/db/schema/nh_sockets.xml
    trunk/db/schema/opensips-nathelper.xml
    trunk/scripts/db_berkeley/opensips/nh_sockets
    trunk/scripts/dbtext/opensips/nh_sockets
    trunk/scripts/mysql/nathelper-create.sql
    trunk/scripts/oracle/nathelper-create.sql
    trunk/scripts/postgres/nathelper-create.sql


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


From noreply at sourceforge.net  Thu Feb 12 15:25:11 2009
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 12 Feb 2009 14:25:11 +0000
Subject: [OpenSIPS-Devel] [ opensips-Patches-2580677 ] Dynamic loading of
	proxies for nathelper module
Message-ID: <E1LXcV5-0003NP-9g@h45xhf1.ch3.sourceforge.com>

Patches item #2580677, was opened at 2009-02-09 06:50
Message generated for change (Comment added) made by anca_vamanu
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086412&aid=2580677&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: Closed
>Resolution: Fixed
Priority: 5
Private: No
Submitted By: Sergio Gutierrez (saguti)
>Assigned to: Anca Vamanu (anca_vamanu)
Summary: Dynamic loading of proxies for nathelper module

Initial Comment:
The attached patch allows to load dynamically the list of proxies used by nathelper module.
It also defines a command which allows to reload the list through management interface.
Dynamic loading of proxies is compatible through loading via configuration file; it is enabled by providing a database url as module parameter.

The table with proxies information has 4 columns: type (unix, udp, udp6), address (ip for udp, udp6; filename for unix), port (N/A for unix), and set id.

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

>Comment By: Anca Vamanu (anca_vamanu)
Date: 2009-02-12 16:25

Message:
Hello,

I have handled this feature request and finally introduced it in code.
Your idea was good, but we decided to change some things in the
implementation:
- database table: the columns address, port and type were concatenated
into one column - rtpproxy_sock (in the way that you had it - the string
was constructed and then parsed by the nathelper_add_rtpproxy_set
function)
- the locking system was not good: I implemented a readers- writer
mechanism.

Anyhow we appreciate your effort and  hope to see more contributions from
your part.

regards,
Anca Vamanu

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

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


From noreply at sourceforge.net  Thu Feb 12 16:44:31 2009
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 12 Feb 2009 15:44:31 +0000
Subject: [OpenSIPS-Devel] [ opensips-Bugs-2593088 ] Crash with db_postgres
	and presence
Message-ID: <E1LXdjr-000209-Q6@d45xhf1.ch3.sourceforge.com>

Bugs item #2593088, was opened at 2009-02-12 13:48
Message generated for change (Comment added) made by nobody
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=2593088&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: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: Crash with db_postgres and presence

Initial Comment:
(submitted by vasil.kolev at attractel.com)

The problem is as follows - a query is executed, but for some reason the results from the previous one are read back from the DB driver, which in turn makes opensips to crash as the number of columns is lower and it tries to dereference stuff that doesn't exist.

Appended are the log and the backtrace:


Feb 12 13:42:59 f-ast2 opensips[29504]: DBG:db_postgres:db_postgres_submit_query: 0x8197240 PQsendQuery(select status,reason from watchers where presentity_uri='sip:bbb%40ccc.com at 10.2.30.5' AND watcher_username='aaa%40ccc.com' AND watcher_domain='10.2.30.5' AND event='presence') 
Feb 12 13:42:59 f-ast2 opensips[29504]: DBG:core:db_new_result: allocate 28 bytes for result set at 0x81a0948 
Feb 12 13:42:59 f-ast2 opensips[29504]: DBG:db_postgres:db_postgres_store_result: 0x8197240 PQresultStatus(PGRES_TUPLES_OK) PQgetResult(0x94c0300) 
Feb 12 13:42:59 f-ast2 opensips[29504]: DBG:db_postgres:db_postgres_get_columns: 1 columns returned from the query 
Feb 12 13:42:59 f-ast2 opensips[29504]: DBG:core:db_allocate_columns: allocate 16 bytes for result columns at 0x819ecd0 
Feb 12 13:42:59 f-ast2 opensips[29504]: DBG:db_postgres:db_postgres_get_columns: RES_NAMES(0x819ecd8)[0]=[username] 
Feb 12 13:42:59 f-ast2 opensips[29504]: DBG:db_postgres:db_postgres_get_columns: use DB_STRING result type 
Feb 12 13:42:59 f-ast2 opensips[29504]: DBG:db_postgres:db_postgres_convert_rows: allocate for 1 columns 4 bytes in row buffer at 0x819d5b8 
Feb 12 13:42:59 f-ast2 opensips[29504]: DBG:core:db_allocate_rows: allocate 28 bytes for result rows and values at 0x819f870 
Feb 12 13:42:59 f-ast2 opensips[29504]: DBG:db_postgres:db_postgres_convert_rows: PQgetvalue(0x8197240,0,0)=[aaa at ccc.com] 
Feb 12 13:42:59 f-ast2 opensips[29504]: DBG:db_postgres:db_postgres_convert_rows: allocated 11 bytes for row_buf[0] at 0x819d5c8 
Feb 12 13:42:59 f-ast2 opensips[29504]: DBG:db_postgres:db_postgres_convert_rows: [0][0] Column[username]=[aaa at ccc.com] 
Feb 12 13:42:59 f-ast2 opensips[29504]: DBG:db_postgres:db_postgres_str2val: converting STRING [aaa at ccc.com] 
Feb 12 13:42:59 f-ast2 opensips[29504]: DBG:db_postgres:db_postgres_convert_rows: freeing row buffer at 0x819d5b8 
Feb 12 13:42:59 f-ast2 opensips[29504]: DBG:db_postgres:free_query: PQclear(0x94c0300) result set 
Feb 12 13:42:59 f-ast2 opensips[29507]: DBG:db_postgres:db_postgres_store_result: 0x8197100 PQresultStatus(PGRES_TUPLES_OK) PQgetResult(0x94bb108) 
Feb 12 13:42:59 f-ast2 kernel: [842163.893756] opensips[29504]: segfault at 1 ip b77b98c6 sp bff1ab30 error 4 in presence.so[b7790000+31000]



Core was generated by `opensips'.
Program terminated with signal 11, Segmentation fault.
[New process 29504]
#0  0xb77b98c6 in get_db_subs_auth (subs=0xbff1acf4, found=0xbff1ad94) at subscribe.c:1980
1980			subs->reason.len= strlen(row_vals[1].val.string_val);
(gdb) bt
#0  0xb77b98c6 in get_db_subs_auth (subs=0xbff1acf4, found=0xbff1ad94) at subscribe.c:1980
#1  0xb77ba5cc in handle_subscribe (msg=0x819acb8, str1=0x0, str2=0x0) at subscribe.c:630
#2  0x08055591 in do_action (a=0x8195940, msg=0x819acb8) at action.c:961
#3  0x080541e2 in run_action_list (a=0x8195940, msg=0x819acb8) at action.c:139
#4  0x08056ecd in do_action (a=0x8195fe0, msg=0x819acb8) at action.c:705
#5  0x080541e2 in run_action_list (a=0x8195fe0, msg=0x819acb8) at action.c:139
#6  0x08057529 in do_action (a=0x8196048, msg=0x819acb8) at action.c:711
#7  0x080541e2 in run_action_list (a=0x81953d0, msg=0x819acb8) at action.c:139
#8  0x08056914 in do_action (a=0x8192808, msg=0x819acb8) at action.c:119
#9  0x080541e2 in run_action_list (a=0x8192808, msg=0x819acb8) at action.c:139
#10 0x08056ecd in do_action (a=0x8192870, msg=0x819acb8) at action.c:705
#11 0x080541e2 in run_action_list (a=0x818d6b8, msg=0x819acb8) at action.c:139
#12 0x08057ee1 in run_top_route (a=0x818d6b8, msg=0x819acb8) at action.c:119
#13 0x0809228c in receive_msg (
    buf=0x8164100 "SUBSCRIBE sip:bbb%40ccc.com at 10.2.30.5;transport=UDP SIP/2.0\r\nVia: SIP/2.0/UDP 10.2.2.179:5060;branch=z9hG4bK-d8754z-1c3f735ee1e02d36-1---d8754z-\r\nMax-Forwards: 69\r\nContact: <sip:aaa%40ccc.com at 10.2.2.1"..., len=793, rcv_info=0xbff1bad4) at receive.c:165
#14 0x080cdf4b in udp_rcv_loop () at udp_server.c:449
#15 0x0806c3af in main (argc=1, argv=0xbff1bc64) at main.c:778



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

Comment By: Nobody/Anonymous (nobody)
Date: 2009-02-12 15:44

Message:
I have been looking into the problem for some time and it seems like
there's a race condition in the postgresql driver somewhere. I have seen
how a query A is made, then query B hits, and then the part that sent B
sees the results of A and crashes opensips.

I'll try to find the place where the lock should happen, but I'll need to
get a bit more familiar with the types of locking primitives used.

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

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


From saguti at gmail.com  Thu Feb 12 18:40:57 2009
From: saguti at gmail.com (Sergio Gutierrez)
Date: Thu, 12 Feb 2009 12:40:57 -0500
Subject: [OpenSIPS-Devel] New feature: Dynamic reloading of RTP Proxies list
	on nathelper module.
Message-ID: <8a4af3e20902120940h3270d6a9ve3c7fcb102151ad1@mail.gmail.com>

Hello to all members.

A new feature has been introduced in nathelper module. Based on an idea
published by one of the developers, and with a complete rework made by Anca
Vamanu, dynamic reloading of RTP proxies list for nathelper module has been
implemented.

This feature allows to provision proxies to OpenSIPS in real time, avoiding
the need to restart, which will help to increase availability of
installations based on OpenSIPS.

RTP Proxies definition will be stored on database, and could be reloaded
through management interface. This mechanism is still compatible with
proxies definition through configuration file.

Dynamic reloading of RTP Proxies is availabe since Revision 5308 of Trunk,
which is available for downloading through SVN (
http://www.opensips.org/index.php?n=Resources.Downloads#svn).

More detailed information about feature can be found in module documentation
(http://www.opensips.org/html/docs/modules/devel/nathelper.html), and in
README file included with source code.

We hope this feature helps to make nathelper module easier to use, and
contributes to increase the scalability and availability of platforms which
use this module

Best regards.

Sergio Guti?rrez.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.opensips.org/pipermail/devel/attachments/20090212/5a35a9c2/attachment.htm 

From noreply at sourceforge.net  Thu Feb 12 19:00:38 2009
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 12 Feb 2009 18:00:38 +0000
Subject: [OpenSIPS-Devel] [ opensips-Bugs-2593088 ] Crash with db_postgres
	and presence
Message-ID: <E1LXfra-0008CC-87@h45xhf1.ch3.sourceforge.com>

Bugs item #2593088, was opened at 2009-02-12 13:48
Message generated for change (Comment added) made by nobody
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=2593088&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: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: Crash with db_postgres and presence

Initial Comment:
(submitted by vasil.kolev at attractel.com)

The problem is as follows - a query is executed, but for some reason the results from the previous one are read back from the DB driver, which in turn makes opensips to crash as the number of columns is lower and it tries to dereference stuff that doesn't exist.

Appended are the log and the backtrace:


Feb 12 13:42:59 f-ast2 opensips[29504]: DBG:db_postgres:db_postgres_submit_query: 0x8197240 PQsendQuery(select status,reason from watchers where presentity_uri='sip:bbb%40ccc.com at 10.2.30.5' AND watcher_username='aaa%40ccc.com' AND watcher_domain='10.2.30.5' AND event='presence') 
Feb 12 13:42:59 f-ast2 opensips[29504]: DBG:core:db_new_result: allocate 28 bytes for result set at 0x81a0948 
Feb 12 13:42:59 f-ast2 opensips[29504]: DBG:db_postgres:db_postgres_store_result: 0x8197240 PQresultStatus(PGRES_TUPLES_OK) PQgetResult(0x94c0300) 
Feb 12 13:42:59 f-ast2 opensips[29504]: DBG:db_postgres:db_postgres_get_columns: 1 columns returned from the query 
Feb 12 13:42:59 f-ast2 opensips[29504]: DBG:core:db_allocate_columns: allocate 16 bytes for result columns at 0x819ecd0 
Feb 12 13:42:59 f-ast2 opensips[29504]: DBG:db_postgres:db_postgres_get_columns: RES_NAMES(0x819ecd8)[0]=[username] 
Feb 12 13:42:59 f-ast2 opensips[29504]: DBG:db_postgres:db_postgres_get_columns: use DB_STRING result type 
Feb 12 13:42:59 f-ast2 opensips[29504]: DBG:db_postgres:db_postgres_convert_rows: allocate for 1 columns 4 bytes in row buffer at 0x819d5b8 
Feb 12 13:42:59 f-ast2 opensips[29504]: DBG:core:db_allocate_rows: allocate 28 bytes for result rows and values at 0x819f870 
Feb 12 13:42:59 f-ast2 opensips[29504]: DBG:db_postgres:db_postgres_convert_rows: PQgetvalue(0x8197240,0,0)=[aaa at ccc.com] 
Feb 12 13:42:59 f-ast2 opensips[29504]: DBG:db_postgres:db_postgres_convert_rows: allocated 11 bytes for row_buf[0] at 0x819d5c8 
Feb 12 13:42:59 f-ast2 opensips[29504]: DBG:db_postgres:db_postgres_convert_rows: [0][0] Column[username]=[aaa at ccc.com] 
Feb 12 13:42:59 f-ast2 opensips[29504]: DBG:db_postgres:db_postgres_str2val: converting STRING [aaa at ccc.com] 
Feb 12 13:42:59 f-ast2 opensips[29504]: DBG:db_postgres:db_postgres_convert_rows: freeing row buffer at 0x819d5b8 
Feb 12 13:42:59 f-ast2 opensips[29504]: DBG:db_postgres:free_query: PQclear(0x94c0300) result set 
Feb 12 13:42:59 f-ast2 opensips[29507]: DBG:db_postgres:db_postgres_store_result: 0x8197100 PQresultStatus(PGRES_TUPLES_OK) PQgetResult(0x94bb108) 
Feb 12 13:42:59 f-ast2 kernel: [842163.893756] opensips[29504]: segfault at 1 ip b77b98c6 sp bff1ab30 error 4 in presence.so[b7790000+31000]



Core was generated by `opensips'.
Program terminated with signal 11, Segmentation fault.
[New process 29504]
#0  0xb77b98c6 in get_db_subs_auth (subs=0xbff1acf4, found=0xbff1ad94) at subscribe.c:1980
1980			subs->reason.len= strlen(row_vals[1].val.string_val);
(gdb) bt
#0  0xb77b98c6 in get_db_subs_auth (subs=0xbff1acf4, found=0xbff1ad94) at subscribe.c:1980
#1  0xb77ba5cc in handle_subscribe (msg=0x819acb8, str1=0x0, str2=0x0) at subscribe.c:630
#2  0x08055591 in do_action (a=0x8195940, msg=0x819acb8) at action.c:961
#3  0x080541e2 in run_action_list (a=0x8195940, msg=0x819acb8) at action.c:139
#4  0x08056ecd in do_action (a=0x8195fe0, msg=0x819acb8) at action.c:705
#5  0x080541e2 in run_action_list (a=0x8195fe0, msg=0x819acb8) at action.c:139
#6  0x08057529 in do_action (a=0x8196048, msg=0x819acb8) at action.c:711
#7  0x080541e2 in run_action_list (a=0x81953d0, msg=0x819acb8) at action.c:139
#8  0x08056914 in do_action (a=0x8192808, msg=0x819acb8) at action.c:119
#9  0x080541e2 in run_action_list (a=0x8192808, msg=0x819acb8) at action.c:139
#10 0x08056ecd in do_action (a=0x8192870, msg=0x819acb8) at action.c:705
#11 0x080541e2 in run_action_list (a=0x818d6b8, msg=0x819acb8) at action.c:139
#12 0x08057ee1 in run_top_route (a=0x818d6b8, msg=0x819acb8) at action.c:119
#13 0x0809228c in receive_msg (
    buf=0x8164100 "SUBSCRIBE sip:bbb%40ccc.com at 10.2.30.5;transport=UDP SIP/2.0\r\nVia: SIP/2.0/UDP 10.2.2.179:5060;branch=z9hG4bK-d8754z-1c3f735ee1e02d36-1---d8754z-\r\nMax-Forwards: 69\r\nContact: <sip:aaa%40ccc.com at 10.2.2.1"..., len=793, rcv_info=0xbff1bad4) at receive.c:165
#14 0x080cdf4b in udp_rcv_loop () at udp_server.c:449
#15 0x0806c3af in main (argc=1, argv=0xbff1bc64) at main.c:778



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

Comment By: Nobody/Anonymous (nobody)
Date: 2009-02-12 18:00

Message:

The issue is as follows:


When you do a query and after that you get context switched to another
thread that does a query, it will execute its own query and see the result
of the previous one. Simple scheme:

Thread A		Thread B
do_query(A)
			do_query(B)
			fetch_result()
...

The result is that thread B crashes, as the results returned are from the
wrong query. I've seen crashes in pretty much every module that uses the DB
connection.

My initial solution was to just add a lock in db_con_t structure and track
it, but that didn't solve the problem, which in turn led me to find that
new connections are initialized in db/db.c in db_do_init(), and there every
new connection is checked if it exists in the pool. So if you use a few
modules with the same database (as I do in my config, I have the same
database/user/pass for uri_db, usrloc, auth_db, presence, presence_xml and
xcap_client), only one entry will be created in the db_pool stuff. This in
turn leads to having multiple db_con_t structures for one DB connection,
which made the lock pretty much useless.

As a hack, I just made the db_do_init() not to check in the pool if a
connection exists, but to just open a new one. This will have a pretty
nasty effect on the number of open database connections (my setup opened
about 70), but at least it shouldn't crash this way. My ugly patch is
available at http://tiki.securax.net/mx/db_lock.diff .

A good solution is to have internal locking per DB connection which in
turn can be accessed with a member of db_func_t from the relevant
functions. I don't seem to have a better idea right now...

-- 
Regards,
Vasil Kolev
Attractel NV
dCAP #1324, LPIC2

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

Comment By: Nobody/Anonymous (nobody)
Date: 2009-02-12 15:44

Message:
I have been looking into the problem for some time and it seems like
there's a race condition in the postgresql driver somewhere. I have seen
how a query A is made, then query B hits, and then the part that sent B
sees the results of A and crashes opensips.

I'll try to find the place where the lock should happen, but I'll need to
get a bit more familiar with the types of locking primitives used.

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

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


From noreply at sourceforge.net  Fri Feb 13 09:53:33 2009
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 13 Feb 2009 08:53:33 +0000
Subject: [OpenSIPS-Devel] [ opensips-Feature Requests-2094884 ] SIP Identity
Message-ID: <E1LXtnh-0004Gh-Oe@565xhf1.ch3.sourceforge.com>

Feature Requests item #2094884, was opened at 2008-09-05 14:13
Message generated for change (Settings changed) made by rootkiskacsa
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086413&aid=2094884&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: M?sz?ros Mih?ly (rootkiskacsa)
Assigned to: Bogdan-Andrei Iancu (bogdan_iancu)
Summary: SIP Identity 

Initial Comment:
It will be nice if OpenSips can support SIP Identity according RFC 4474.

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

>Comment By: M?sz?ros Mih?ly (rootkiskacsa)
Date: 2009-02-13 09:53

Message:
Thank YOU!

If i will have a little time I will test it!

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

Comment By: Bogdan-Andrei Iancu (bogdan_iancu)
Date: 2009-02-11 11:18

Message:
Ok - the Identity module is on SVN - please test.

Thanks and regards,
Bogdan

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

Comment By: Bogdan-Andrei Iancu (bogdan_iancu)
Date: 2008-10-03 16:14

Message:
there is already an implementation for it, but never approved because there
where some technical issue - but I could try to work it out. I will dig for
the code and upload it here.

Regards,
Bogdan

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

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


From noreply at sourceforge.net  Fri Feb 13 20:58:08 2009
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 13 Feb 2009 19:58:08 +0000
Subject: [OpenSIPS-Devel] [ opensips-Bugs-2274274 ] seg fault in db_postgres
Message-ID: <E1LY4Aq-0005SW-6w@d55xhf1.ch3.sourceforge.com>

Bugs item #2274274, was opened at 2008-11-12 22:25
Message generated for change (Comment added) made by brent_thomson
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=2274274&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: Brent (brent_thomson)
Assigned to: Nobody/Anonymous (nobody)
Summary: seg fault in db_postgres

Initial Comment:
Partial output:

*** glibc detected *** opensips: free(): invalid next size (fast): 0x0000000001166c70 ***
======= Backtrace: =========
/lib64/libc.so.6[0x2b92149b8684]
/lib64/libc.so.6(cfree+0x8c)[0x2b92149bbccc]
/usr/lib64/libpq.so.5(PQsendQuery+0x69)[0x2b921642a819]
/usr/lib64/opensips/modules/db_postgres.so[0x2b921620f0df]
opensips(db_do_query+0x335)[0x4b0da1]
/usr/lib64/opensips/modules/db_postgres.so(db_postgres_query+0x8a)[0x2b921620fd59]
/usr/lib64/opensips/modules/auth_db.so[0x2b92181ae5f1]
/usr/lib64/opensips/modules/auth_db.so[0x2b92181ae0f1]
/usr/lib64/opensips/modules/auth_db.so(proxy_authorize+0x2a)[0x2b92181adec8]
opensips(do_action+0x24d4)[0x410de0]
opensips(run_action_list+0x32)[0x40e1fa]
opensips[0x44d7aa]
opensips(eval_expr+0xc8)[0x451633]
opensips(eval_expr+0x1ac)[0x451717]
opensips(eval_expr+0x1e0)[0x45174b]
opensips(do_action+0x1caf)[0x4105bb]
opensips(run_action_list+0x32)[0x40e1fa]
opensips(do_action+0x1de0)[0x4106ec]
opensips(run_action_list+0x32)[0x40e1fa]
opensips[0x40e46e]
opensips(do_action+0x103b)[0x40f947]
opensips(run_action_list+0x32)[0x40e1fa]
opensips(do_action+0x1de0)[0x4106ec]
opensips(run_action_list+0x32)[0x40e1fa]
opensips[0x40e46e]
opensips(run_top_route+0x61)[0x40e526]
opensips(receive_msg+0x51f)[0x445da6]
opensips(udp_rcv_loop+0x45c)[0x47af5b]
opensips[0x4219ad]
opensips(main+0x1c74)[0x423ccf]
/lib64/libc.so.6(__libc_start_main+0xf4)[0x2b92149648b4]
opensips[0x40e119]

CentOS 5.2
OpenSIPS: latest from svn (about an hour ago)
PostgreSQL libs: 8.3.4 (built against the same)
DB in writeback mode

Causes OpenSIPS to crash every time within a few minutes of starting. I can reproduce the crash by repeatedly reregistering a hard or soft phone, making a call from a successfully registered device, or anything else that touches the database. Reference build and config is OpenSER 1.2, which does not have the problem.

The core dump is too large to attach so I've posted it here:

http://www.sendspace.com/file/1pv989


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

>Comment By: Brent (brent_thomson)
Date: 2009-02-13 12:58

Message:
Hmmm ... That was some time ago. Let me see if I can reproduce it and put
up a log file.

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

Comment By: Sergio Gutierrez (saguti)
Date: 2009-02-09 22:10

Message:
Hello Brent.

I was reviewing your report. Please, could you post OpenSIPS log before
Segmentation Fault?

Regards.

Sergio.

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

Comment By: Brent (brent_thomson)
Date: 2008-11-18 11:05

Message:
Is this what you need?

(gdb) bt
#0  0x00002b9e74dc7155 in raise () from /lib64/libc.so.6
#1  0x00002b9e74dc8bf0 in abort () from /lib64/libc.so.6
#2  0x00002b9e74e013db in __libc_message () from /lib64/libc.so.6
#3  0x00002b9e74e08684 in _int_free () from /lib64/libc.so.6
#4  0x00002b9e74e0bccc in free () from /lib64/libc.so.6
#5  0x00002b9e768797e9 in PQclear () from /usr/lib64/libpq.so.5
#6  0x00002b9e7665fbe9 in free_query (_con=0x779fe8) at dbase.c:320
#7  0x00002b9e7666037d in db_postgres_store_result (_con=0x779fe8,
_r=0x7fff368d58b8)
    at dbase.c:475
#8  0x00000000004b0634 in db_do_query ()
#9  0x00002b9e7665fcc9 in db_postgres_query (_h=0x779fe8,
_k=0x7fff368d5830, _op=0x0, 
    _v=0x7fff368d57f0, _c=0x7802e0, _n=1, _nc=2, _o=0x0,
_r=0x7fff368d58b8) at dbase.c:363
#10 0x00002b9e785fd5b1 in get_ha1 (_username=0x780948,
_domain=0x7fff368d58d0, 
    _table=0x7fff368d58c0, _ha1=0x7fff368d58f0 "", res=0x7fff368d58b8) at
authorize.c:101
#11 0x00002b9e785fd0b1 in authorize (_m=0x77f328, _realm=0x779f30,
_table=0x7737a8 "subscriber", 
    _hftype=HDR_AUTHORIZATION_T) at authorize.c:244
#12 0x00002b9e785fd9fd in www_authorize (_m=0x77f328, _realm=0x779f30
"\001", 
    _table=0x7737a8 "subscriber") at authorize.c:287
#13 0x00000000004105f0 in do_action ()
#14 0x000000000040da0a in run_action_list ()
#15 0x000000000044cfba in eval_elem ()
#16 0x0000000000450e43 in eval_expr ()
#17 0x0000000000450f27 in eval_expr ()
#18 0x0000000000450f5b in eval_expr ()
#19 0x000000000040fdcb in do_action ()
#20 0x000000000040da0a in run_action_list ()
#21 0x000000000040dc7e in run_actions ()
#22 0x000000000040f157 in do_action ()
#23 0x000000000040da0a in run_action_list ()
#24 0x000000000044cfba in eval_elem ()
#25 0x0000000000450e43 in eval_expr ()
#26 0x0000000000450f5b in eval_expr ()
#27 0x000000000040fdcb in do_action ()
#28 0x000000000040da0a in run_action_list ()
#29 0x000000000040fefc in do_action ()
#30 0x000000000040da0a in run_action_list ()
#31 0x000000000040dc7e in run_actions ()
#32 0x000000000040dd36 in run_top_route ()
#33 0x00000000004455b6 in receive_msg ()
#34 0x000000000047a76b in udp_rcv_loop ()
#35 0x0000000000421501 in main_loop ()
#36 0x00000000004234df in main ()


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

Comment By: Brent (brent_thomson)
Date: 2008-11-18 10:17

Message:
That backtrace is the output from opensips itself, with debugging set to 9.
I'm not a gdb jedi. Can you give me instructions or point me to what I need
to do to generate what you're asking for? Is it just a matter of running
the binary in the debugger and then grabbing the output when it crashes?

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

Comment By: Sergio Gutierrez (saguti)
Date: 2008-11-17 17:19

Message:
Hello Brent.

Is that backtrace taken with gdb? The syntax does not loke familiar.
In case it does not, could you take the backtrace with gdb?

Regards.

Sergio.

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

Comment By: Nobody/Anonymous (nobody)
Date: 2008-11-17 16:59

Message:
After fiddling with this some more, it appears that I can only reproduce
this consistently if fork=yes in opensips.cfg. If I don't daemonize
opensips (run it bare, rather than through the init script) and let all the
output go to the console, it no longer crashes.

Please let me know if there's any other useful information that I can
provide.

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

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


From noreply at sourceforge.net  Fri Feb 13 22:02:42 2009
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 13 Feb 2009 21:02:42 +0000
Subject: [OpenSIPS-Devel] [ opensips-Bugs-2274274 ] seg fault in db_postgres
Message-ID: <E1LY5BK-0003GL-Vu@1bkjzd1.ch3.sourceforge.com>

Bugs item #2274274, was opened at 2008-11-13 05:25
Message generated for change (Comment added) made by nobody
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=2274274&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: Brent (brent_thomson)
Assigned to: Nobody/Anonymous (nobody)
Summary: seg fault in db_postgres

Initial Comment:
Partial output:

*** glibc detected *** opensips: free(): invalid next size (fast): 0x0000000001166c70 ***
======= Backtrace: =========
/lib64/libc.so.6[0x2b92149b8684]
/lib64/libc.so.6(cfree+0x8c)[0x2b92149bbccc]
/usr/lib64/libpq.so.5(PQsendQuery+0x69)[0x2b921642a819]
/usr/lib64/opensips/modules/db_postgres.so[0x2b921620f0df]
opensips(db_do_query+0x335)[0x4b0da1]
/usr/lib64/opensips/modules/db_postgres.so(db_postgres_query+0x8a)[0x2b921620fd59]
/usr/lib64/opensips/modules/auth_db.so[0x2b92181ae5f1]
/usr/lib64/opensips/modules/auth_db.so[0x2b92181ae0f1]
/usr/lib64/opensips/modules/auth_db.so(proxy_authorize+0x2a)[0x2b92181adec8]
opensips(do_action+0x24d4)[0x410de0]
opensips(run_action_list+0x32)[0x40e1fa]
opensips[0x44d7aa]
opensips(eval_expr+0xc8)[0x451633]
opensips(eval_expr+0x1ac)[0x451717]
opensips(eval_expr+0x1e0)[0x45174b]
opensips(do_action+0x1caf)[0x4105bb]
opensips(run_action_list+0x32)[0x40e1fa]
opensips(do_action+0x1de0)[0x4106ec]
opensips(run_action_list+0x32)[0x40e1fa]
opensips[0x40e46e]
opensips(do_action+0x103b)[0x40f947]
opensips(run_action_list+0x32)[0x40e1fa]
opensips(do_action+0x1de0)[0x4106ec]
opensips(run_action_list+0x32)[0x40e1fa]
opensips[0x40e46e]
opensips(run_top_route+0x61)[0x40e526]
opensips(receive_msg+0x51f)[0x445da6]
opensips(udp_rcv_loop+0x45c)[0x47af5b]
opensips[0x4219ad]
opensips(main+0x1c74)[0x423ccf]
/lib64/libc.so.6(__libc_start_main+0xf4)[0x2b92149648b4]
opensips[0x40e119]

CentOS 5.2
OpenSIPS: latest from svn (about an hour ago)
PostgreSQL libs: 8.3.4 (built against the same)
DB in writeback mode

Causes OpenSIPS to crash every time within a few minutes of starting. I can reproduce the crash by repeatedly reregistering a hard or soft phone, making a call from a successfully registered device, or anything else that touches the database. Reference build and config is OpenSER 1.2, which does not have the problem.

The core dump is too large to attach so I've posted it here:

http://www.sendspace.com/file/1pv989


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

Comment By: Nobody/Anonymous (nobody)
Date: 2009-02-13 21:02

Message:
Brent, do you feel like getting the patch from issue 2593088 and to try
with it? It seems like the same issue.

Keep in mind that it will make a ton of connections to the database (in my
case they were 70).


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

Comment By: Brent (brent_thomson)
Date: 2009-02-13 19:58

Message:
Hmmm ... That was some time ago. Let me see if I can reproduce it and put
up a log file.

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

Comment By: Sergio Gutierrez (saguti)
Date: 2009-02-10 05:10

Message:
Hello Brent.

I was reviewing your report. Please, could you post OpenSIPS log before
Segmentation Fault?

Regards.

Sergio.

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

Comment By: Brent (brent_thomson)
Date: 2008-11-18 18:05

Message:
Is this what you need?

(gdb) bt
#0  0x00002b9e74dc7155 in raise () from /lib64/libc.so.6
#1  0x00002b9e74dc8bf0 in abort () from /lib64/libc.so.6
#2  0x00002b9e74e013db in __libc_message () from /lib64/libc.so.6
#3  0x00002b9e74e08684 in _int_free () from /lib64/libc.so.6
#4  0x00002b9e74e0bccc in free () from /lib64/libc.so.6
#5  0x00002b9e768797e9 in PQclear () from /usr/lib64/libpq.so.5
#6  0x00002b9e7665fbe9 in free_query (_con=0x779fe8) at dbase.c:320
#7  0x00002b9e7666037d in db_postgres_store_result (_con=0x779fe8,
_r=0x7fff368d58b8)
    at dbase.c:475
#8  0x00000000004b0634 in db_do_query ()
#9  0x00002b9e7665fcc9 in db_postgres_query (_h=0x779fe8,
_k=0x7fff368d5830, _op=0x0, 
    _v=0x7fff368d57f0, _c=0x7802e0, _n=1, _nc=2, _o=0x0,
_r=0x7fff368d58b8) at dbase.c:363
#10 0x00002b9e785fd5b1 in get_ha1 (_username=0x780948,
_domain=0x7fff368d58d0, 
    _table=0x7fff368d58c0, _ha1=0x7fff368d58f0 "", res=0x7fff368d58b8) at
authorize.c:101
#11 0x00002b9e785fd0b1 in authorize (_m=0x77f328, _realm=0x779f30,
_table=0x7737a8 "subscriber", 
    _hftype=HDR_AUTHORIZATION_T) at authorize.c:244
#12 0x00002b9e785fd9fd in www_authorize (_m=0x77f328, _realm=0x779f30
"\001", 
    _table=0x7737a8 "subscriber") at authorize.c:287
#13 0x00000000004105f0 in do_action ()
#14 0x000000000040da0a in run_action_list ()
#15 0x000000000044cfba in eval_elem ()
#16 0x0000000000450e43 in eval_expr ()
#17 0x0000000000450f27 in eval_expr ()
#18 0x0000000000450f5b in eval_expr ()
#19 0x000000000040fdcb in do_action ()
#20 0x000000000040da0a in run_action_list ()
#21 0x000000000040dc7e in run_actions ()
#22 0x000000000040f157 in do_action ()
#23 0x000000000040da0a in run_action_list ()
#24 0x000000000044cfba in eval_elem ()
#25 0x0000000000450e43 in eval_expr ()
#26 0x0000000000450f5b in eval_expr ()
#27 0x000000000040fdcb in do_action ()
#28 0x000000000040da0a in run_action_list ()
#29 0x000000000040fefc in do_action ()
#30 0x000000000040da0a in run_action_list ()
#31 0x000000000040dc7e in run_actions ()
#32 0x000000000040dd36 in run_top_route ()
#33 0x00000000004455b6 in receive_msg ()
#34 0x000000000047a76b in udp_rcv_loop ()
#35 0x0000000000421501 in main_loop ()
#36 0x00000000004234df in main ()


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

Comment By: Brent (brent_thomson)
Date: 2008-11-18 17:17

Message:
That backtrace is the output from opensips itself, with debugging set to 9.
I'm not a gdb jedi. Can you give me instructions or point me to what I need
to do to generate what you're asking for? Is it just a matter of running
the binary in the debugger and then grabbing the output when it crashes?

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

Comment By: Sergio Gutierrez (saguti)
Date: 2008-11-18 00:19

Message:
Hello Brent.

Is that backtrace taken with gdb? The syntax does not loke familiar.
In case it does not, could you take the backtrace with gdb?

Regards.

Sergio.

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

Comment By: Nobody/Anonymous (nobody)
Date: 2008-11-17 23:59

Message:
After fiddling with this some more, it appears that I can only reproduce
this consistently if fork=yes in opensips.cfg. If I don't daemonize
opensips (run it bare, rather than through the init script) and let all the
output go to the console, it no longer crashes.

Please let me know if there's any other useful information that I can
provide.

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

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


From noreply at sourceforge.net  Fri Feb 13 22:47:16 2009
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 13 Feb 2009 21:47:16 +0000
Subject: [OpenSIPS-Devel] [ opensips-Bugs-2274274 ] seg fault in db_postgres
Message-ID: <E1LY5sS-0004JE-07@665xhf1.ch3.sourceforge.com>

Bugs item #2274274, was opened at 2008-11-12 22:25
Message generated for change (Comment added) made by brent_thomson
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=2274274&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: Brent (brent_thomson)
Assigned to: Nobody/Anonymous (nobody)
Summary: seg fault in db_postgres

Initial Comment:
Partial output:

*** glibc detected *** opensips: free(): invalid next size (fast): 0x0000000001166c70 ***
======= Backtrace: =========
/lib64/libc.so.6[0x2b92149b8684]
/lib64/libc.so.6(cfree+0x8c)[0x2b92149bbccc]
/usr/lib64/libpq.so.5(PQsendQuery+0x69)[0x2b921642a819]
/usr/lib64/opensips/modules/db_postgres.so[0x2b921620f0df]
opensips(db_do_query+0x335)[0x4b0da1]
/usr/lib64/opensips/modules/db_postgres.so(db_postgres_query+0x8a)[0x2b921620fd59]
/usr/lib64/opensips/modules/auth_db.so[0x2b92181ae5f1]
/usr/lib64/opensips/modules/auth_db.so[0x2b92181ae0f1]
/usr/lib64/opensips/modules/auth_db.so(proxy_authorize+0x2a)[0x2b92181adec8]
opensips(do_action+0x24d4)[0x410de0]
opensips(run_action_list+0x32)[0x40e1fa]
opensips[0x44d7aa]
opensips(eval_expr+0xc8)[0x451633]
opensips(eval_expr+0x1ac)[0x451717]
opensips(eval_expr+0x1e0)[0x45174b]
opensips(do_action+0x1caf)[0x4105bb]
opensips(run_action_list+0x32)[0x40e1fa]
opensips(do_action+0x1de0)[0x4106ec]
opensips(run_action_list+0x32)[0x40e1fa]
opensips[0x40e46e]
opensips(do_action+0x103b)[0x40f947]
opensips(run_action_list+0x32)[0x40e1fa]
opensips(do_action+0x1de0)[0x4106ec]
opensips(run_action_list+0x32)[0x40e1fa]
opensips[0x40e46e]
opensips(run_top_route+0x61)[0x40e526]
opensips(receive_msg+0x51f)[0x445da6]
opensips(udp_rcv_loop+0x45c)[0x47af5b]
opensips[0x4219ad]
opensips(main+0x1c74)[0x423ccf]
/lib64/libc.so.6(__libc_start_main+0xf4)[0x2b92149648b4]
opensips[0x40e119]

CentOS 5.2
OpenSIPS: latest from svn (about an hour ago)
PostgreSQL libs: 8.3.4 (built against the same)
DB in writeback mode

Causes OpenSIPS to crash every time within a few minutes of starting. I can reproduce the crash by repeatedly reregistering a hard or soft phone, making a call from a successfully registered device, or anything else that touches the database. Reference build and config is OpenSER 1.2, which does not have the problem.

The core dump is too large to attach so I've posted it here:

http://www.sendspace.com/file/1pv989


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

>Comment By: Brent (brent_thomson)
Date: 2009-02-13 14:47

Message:
Doesn't really sound like a fix ... and 70 connections isn't acceptable. I
think I'll look for things that have changed since openser 1.3.2, which
doesn't have this issue.

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

Comment By: Nobody/Anonymous (nobody)
Date: 2009-02-13 14:02

Message:
Brent, do you feel like getting the patch from issue 2593088 and to try
with it? It seems like the same issue.

Keep in mind that it will make a ton of connections to the database (in my
case they were 70).


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

Comment By: Brent (brent_thomson)
Date: 2009-02-13 12:58

Message:
Hmmm ... That was some time ago. Let me see if I can reproduce it and put
up a log file.

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

Comment By: Sergio Gutierrez (saguti)
Date: 2009-02-09 22:10

Message:
Hello Brent.

I was reviewing your report. Please, could you post OpenSIPS log before
Segmentation Fault?

Regards.

Sergio.

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

Comment By: Brent (brent_thomson)
Date: 2008-11-18 11:05

Message:
Is this what you need?

(gdb) bt
#0  0x00002b9e74dc7155 in raise () from /lib64/libc.so.6
#1  0x00002b9e74dc8bf0 in abort () from /lib64/libc.so.6
#2  0x00002b9e74e013db in __libc_message () from /lib64/libc.so.6
#3  0x00002b9e74e08684 in _int_free () from /lib64/libc.so.6
#4  0x00002b9e74e0bccc in free () from /lib64/libc.so.6
#5  0x00002b9e768797e9 in PQclear () from /usr/lib64/libpq.so.5
#6  0x00002b9e7665fbe9 in free_query (_con=0x779fe8) at dbase.c:320
#7  0x00002b9e7666037d in db_postgres_store_result (_con=0x779fe8,
_r=0x7fff368d58b8)
    at dbase.c:475
#8  0x00000000004b0634 in db_do_query ()
#9  0x00002b9e7665fcc9 in db_postgres_query (_h=0x779fe8,
_k=0x7fff368d5830, _op=0x0, 
    _v=0x7fff368d57f0, _c=0x7802e0, _n=1, _nc=2, _o=0x0,
_r=0x7fff368d58b8) at dbase.c:363
#10 0x00002b9e785fd5b1 in get_ha1 (_username=0x780948,
_domain=0x7fff368d58d0, 
    _table=0x7fff368d58c0, _ha1=0x7fff368d58f0 "", res=0x7fff368d58b8) at
authorize.c:101
#11 0x00002b9e785fd0b1 in authorize (_m=0x77f328, _realm=0x779f30,
_table=0x7737a8 "subscriber", 
    _hftype=HDR_AUTHORIZATION_T) at authorize.c:244
#12 0x00002b9e785fd9fd in www_authorize (_m=0x77f328, _realm=0x779f30
"\001", 
    _table=0x7737a8 "subscriber") at authorize.c:287
#13 0x00000000004105f0 in do_action ()
#14 0x000000000040da0a in run_action_list ()
#15 0x000000000044cfba in eval_elem ()
#16 0x0000000000450e43 in eval_expr ()
#17 0x0000000000450f27 in eval_expr ()
#18 0x0000000000450f5b in eval_expr ()
#19 0x000000000040fdcb in do_action ()
#20 0x000000000040da0a in run_action_list ()
#21 0x000000000040dc7e in run_actions ()
#22 0x000000000040f157 in do_action ()
#23 0x000000000040da0a in run_action_list ()
#24 0x000000000044cfba in eval_elem ()
#25 0x0000000000450e43 in eval_expr ()
#26 0x0000000000450f5b in eval_expr ()
#27 0x000000000040fdcb in do_action ()
#28 0x000000000040da0a in run_action_list ()
#29 0x000000000040fefc in do_action ()
#30 0x000000000040da0a in run_action_list ()
#31 0x000000000040dc7e in run_actions ()
#32 0x000000000040dd36 in run_top_route ()
#33 0x00000000004455b6 in receive_msg ()
#34 0x000000000047a76b in udp_rcv_loop ()
#35 0x0000000000421501 in main_loop ()
#36 0x00000000004234df in main ()


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

Comment By: Brent (brent_thomson)
Date: 2008-11-18 10:17

Message:
That backtrace is the output from opensips itself, with debugging set to 9.
I'm not a gdb jedi. Can you give me instructions or point me to what I need
to do to generate what you're asking for? Is it just a matter of running
the binary in the debugger and then grabbing the output when it crashes?

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

Comment By: Sergio Gutierrez (saguti)
Date: 2008-11-17 17:19

Message:
Hello Brent.

Is that backtrace taken with gdb? The syntax does not loke familiar.
In case it does not, could you take the backtrace with gdb?

Regards.

Sergio.

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

Comment By: Nobody/Anonymous (nobody)
Date: 2008-11-17 16:59

Message:
After fiddling with this some more, it appears that I can only reproduce
this consistently if fork=yes in opensips.cfg. If I don't daemonize
opensips (run it bare, rather than through the init script) and let all the
output go to the console, it no longer crashes.

Please let me know if there's any other useful information that I can
provide.

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

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


From noreply at sourceforge.net  Sat Feb 14 22:06:31 2009
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat, 14 Feb 2009 21:06:31 +0000
Subject: [OpenSIPS-Devel] [ opensips-Feature Requests-2094884 ] SIP Identity
Message-ID: <E1LYRiZ-0008Ct-59@g45xhf1.ch3.sourceforge.com>

Feature Requests item #2094884, was opened at 2008-09-05 15:13
Message generated for change (Settings changed) made by bogdan_iancu
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086413&aid=2094884&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
Priority: 5
Private: No
Submitted By: M?sz?ros Mih?ly (rootkiskacsa)
Assigned to: Bogdan-Andrei Iancu (bogdan_iancu)
Summary: SIP Identity 

Initial Comment:
It will be nice if OpenSips can support SIP Identity according RFC 4474.

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

Comment By: M?sz?ros Mih?ly (rootkiskacsa)
Date: 2009-02-13 10:53

Message:
Thank YOU!

If i will have a little time I will test it!

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

Comment By: Bogdan-Andrei Iancu (bogdan_iancu)
Date: 2009-02-11 12:18

Message:
Ok - the Identity module is on SVN - please test.

Thanks and regards,
Bogdan

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

Comment By: Bogdan-Andrei Iancu (bogdan_iancu)
Date: 2008-10-03 17:14

Message:
there is already an implementation for it, but never approved because there
where some technical issue - but I could try to work it out. I will dig for
the code and upload it here.

Regards,
Bogdan

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

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


From bogdan at voice-system.ro  Sat Feb 14 23:05:40 2009
From: bogdan at voice-system.ro (Bogdan-Andrei Iancu)
Date: Sat, 14 Feb 2009 22:05:40 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[5309]
	trunk/modules/load_balancer
Message-ID: <E1LYSdo-00027u-34@3kljzd1.ch3.sourceforge.com>

Revision: 5309
          http://opensips.svn.sourceforge.net/opensips/?rev=5309&view=rev
Author:   bogdan_iancu
Date:     2009-02-14 22:05:39 +0000 (Sat, 14 Feb 2009)

Log Message:
-----------
- 2 new MI commands:
  "lb_resize" for changing at runtime the maximum load accepted by a resource
  "lb_list" for listing the current destination and their load

Modified Paths:
--------------
    trunk/modules/load_balancer/lb_data.c
    trunk/modules/load_balancer/load_balancer.c


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


From bogdan at voice-system.ro  Sat Feb 14 23:13:55 2009
From: bogdan at voice-system.ro (Bogdan-Andrei Iancu)
Date: Sat, 14 Feb 2009 22:13:55 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[5310]
	trunk/modules/dialog/dlg_hash.c
Message-ID: <E1LYSln-0002IL-Jg@3kljzd1.ch3.sourceforge.com>

Revision: 5310
          http://opensips.svn.sourceforge.net/opensips/?rev=5310&view=rev
Author:   bogdan_iancu
Date:     2009-02-14 22:13:55 +0000 (Sat, 14 Feb 2009)

Log Message:
-----------
- added flush support (at each 50 dialogs) for MI functions listing all existing dialogs

Modified Paths:
--------------
    trunk/modules/dialog/dlg_hash.c


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


From bogdan at voice-system.ro  Sat Feb 14 23:16:03 2009
From: bogdan at voice-system.ro (Bogdan-Andrei Iancu)
Date: Sat, 14 Feb 2009 22:16:03 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[5311] trunk/modules/dialog
Message-ID: <E1LYSnr-0002LE-Pm@3kljzd1.ch3.sourceforge.com>

Revision: 5311
          http://opensips.svn.sourceforge.net/opensips/?rev=5311&view=rev
Author:   bogdan_iancu
Date:     2009-02-14 22:16:03 +0000 (Sat, 14 Feb 2009)

Log Message:
-----------
The patch add a callback type DLGCB_SAVED. The callback is then called each
time the dialog is saved into database. This feature is interesting for
modules that need to save additional information into database.
- The module can then benefit all database scheduling from dialog
(none/realtime/delayed/shutdone).
- Data saved by dialog and by the module are synchronous.
- The cell->flags can help the callback to know if data needs to be
inserted, updated or deleted

Closes patch #2591385.
Contributed by Hugues Mitonneau.

Modified Paths:
--------------
    trunk/modules/dialog/dlg_cb.h
    trunk/modules/dialog/dlg_db_handler.c
    trunk/modules/dialog/doc/dialog_devel.xml


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


From noreply at sourceforge.net  Sat Feb 14 23:16:25 2009
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat, 14 Feb 2009 22:16:25 +0000
Subject: [OpenSIPS-Devel] [ opensips-Patches-2585066 ] new feature: dialog
	on saved callback
Message-ID: <E1LYSoD-0001m6-A4@565xhf1.ch3.sourceforge.com>

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

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: modules
Group: trunk
>Status: Closed
>Resolution: Accepted
Priority: 5
Private: No
Submitted By: Hugues Mitonneau (hmitonneau)
>Assigned to: Bogdan-Andrei Iancu (bogdan_iancu)
Summary: new feature: dialog on saved callback

Initial Comment:
The patch add a callback type DLGCB_SAVED. The callback is then called each time the dialog is saved into database. This feature is interesting for modules that need to save additional information into database.
- The module can then benefit all database scheduling from dialog (none/realtime/delayed/shutdone).
- Data saved by dialog and by the module are synchronous.
- The cell->flags can help the callback to know if data needs to be inserted, updated or deleted.

Hugues


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

>Comment By: Bogdan-Andrei Iancu (bogdan_iancu)
Date: 2009-02-15 00:16

Message:
Thanks for the patch - it is on SVN.

Regards,
Bogdan

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

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


From bogdan at voice-system.ro  Sat Feb 14 23:23:43 2009
From: bogdan at voice-system.ro (Bogdan-Andrei Iancu)
Date: Sat, 14 Feb 2009 22:23:43 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[5312] trunk/modules/acc/acc.c
Message-ID: <E1LYSvH-0002pS-DM@3kljzd1.ch3.sourceforge.com>

Revision: 5312
          http://opensips.svn.sourceforge.net/opensips/?rev=5312&view=rev
Author:   bogdan_iancu
Date:     2009-02-14 22:23:43 +0000 (Sat, 14 Feb 2009)

Log Message:
-----------
The acc module is able to generate only 'Start', 'Stop' and 'Failed' radius
requests. For in-dialog SIP requests (like reINVITEs) a 'Start' radius
request is generated. The correct behavior would be to generate an 'Alive'
radius request.
The attached patch is adding the new 'Alive' radius request and generates
them based on the existence of the To tag.

Closes patch #2591385
Contributed 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 noreply at sourceforge.net  Sat Feb 14 23:24:33 2009
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat, 14 Feb 2009 22:24:33 +0000
Subject: [OpenSIPS-Devel] [ opensips-Patches-2591385 ] acc: in-dialog SIP
	req should generate 'Alive' radius req
Message-ID: <E1LYSw5-0004zS-SY@g45xhf1.ch3.sourceforge.com>

Patches item #2591385, was opened at 2009-02-12 04:48
Message generated for change (Comment added) made by bogdan_iancu
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086412&aid=2591385&group_id=232389

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: modules
Group: trunk
>Status: Closed
>Resolution: Accepted
Priority: 5
Private: No
Submitted By: Ovidiu Sas (osas)
>Assigned to: Bogdan-Andrei Iancu (bogdan_iancu)
Summary: acc: in-dialog SIP req should generate 'Alive' radius req

Initial Comment:
The acc module is able to generate only 'Start', 'Stop' and 'Failed' radius requests.  For in-dialog SIP requests (like reINVITEs) a 'Start' radius request is generated.  The correct behavior would be to generate an 'Alive' radius request.
The attached patch is adding the new 'Alive' radius request and generates them based on the existence of the To tag.

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

>Comment By: Bogdan-Andrei Iancu (bogdan_iancu)
Date: 2009-02-15 00:24

Message:
Hi Ovidiu,

Thank you for the patch - it is applied on SVN trunk.

Regards,
Bogdan

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

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


From bogdan at voice-system.ro  Sat Feb 14 23:26:48 2009
From: bogdan at voice-system.ro (Bogdan-Andrei Iancu)
Date: Sat, 14 Feb 2009 22:26:48 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[5313] trunk/modules/uac/uac.c
Message-ID: <E1LYSyG-0002ss-0K@3kljzd1.ch3.sourceforge.com>

Revision: 5313
          http://opensips.svn.sourceforge.net/opensips/?rev=5313&view=rev
Author:   bogdan_iancu
Date:     2009-02-14 22:26:47 +0000 (Sat, 14 Feb 2009)

Log Message:
-----------
 uac_replace_from() functions enabled from FAILURE and BRANCH routes

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


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


From bogdan at voice-system.ro  Sat Feb 14 23:32:01 2009
From: bogdan at voice-system.ro (Bogdan-Andrei Iancu)
Date: Sat, 14 Feb 2009 22:32:01 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[5314]
	trunk/modules/textops/textops.c
Message-ID: <E1LYT3J-0002wV-IL@3kljzd1.ch3.sourceforge.com>

Revision: 5314
          http://opensips.svn.sourceforge.net/opensips/?rev=5314&view=rev
Author:   bogdan_iancu
Date:     2009-02-14 22:32:01 +0000 (Sat, 14 Feb 2009)

Log Message:
-----------
When 'content-type' is not the last header of a multipart content,
remaining headers were not filtered out.

Closed patch #2538033.
Contributed by Hugues Mitonneau

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


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


From bogdan at voice-system.ro  Sat Feb 14 23:34:01 2009
From: bogdan at voice-system.ro (Bogdan-Andrei Iancu)
Date: Sat, 14 Feb 2009 22:34:01 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[5315]
	branches/1.4/modules/textops/textops.c
Message-ID: <E1LYT5F-0002yU-Eg@3kljzd1.ch3.sourceforge.com>

Revision: 5315
          http://opensips.svn.sourceforge.net/opensips/?rev=5315&view=rev
Author:   bogdan_iancu
Date:     2009-02-14 22:34:01 +0000 (Sat, 14 Feb 2009)

Log Message:
-----------
backport from trunk (rev #5314):

When 'content-type' is not the last header of a multipart content,
remaining headers were not filtered out.

Closed patch #2538033.
Contributed by Hugues Mitonneau

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

Modified Paths:
--------------
    branches/1.4/modules/textops/textops.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 Feb 14 23:34:33 2009
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat, 14 Feb 2009 22:34:33 +0000
Subject: [OpenSIPS-Devel] [ opensips-Patches-2538033 ] filter all body
	headers during filter_body
Message-ID: <E1LYT5l-0004HI-UM@1bkjzd1.ch3.sourceforge.com>

Patches item #2538033, was opened at 2009-01-26 18:36
Message generated for change (Comment added) made by bogdan_iancu
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086412&aid=2538033&group_id=232389

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: modules
Group: trunk
>Status: Closed
Resolution: Accepted
Priority: 5
Private: No
Submitted By: Hugues Mitonneau (hmitonneau)
Assigned to: Bogdan-Andrei Iancu (bogdan_iancu)
Summary: filter all body headers during filter_body

Initial Comment:
When 'content-type' is not the last header of a multipart content, remaining headers were not filtered out.
For example, if a multipart contains something like this, the 'Content-Length' header was not filtered, resulting in an invalid sdp content:
> --Boundary
> Content-Type: application/sdp
> Content-Length: 488
> 
> ...
> --Boundary--


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

>Comment By: Bogdan-Andrei Iancu (bogdan_iancu)
Date: 2009-02-15 00:34

Message:
Hi Hugues,

Thanks for the fix -  I applied it on both trunk and 1.4 branch.

Regards,
Bogdan

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

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


From bogdan at voice-system.ro  Sat Feb 14 23:42:02 2009
From: bogdan at voice-system.ro (Bogdan-Andrei Iancu)
Date: Sat, 14 Feb 2009 22:42:02 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[5316] trunk/modules/dialog
Message-ID: <E1LYTD0-00036l-Ft@3kljzd1.ch3.sourceforge.com>

Revision: 5316
          http://opensips.svn.sourceforge.net/opensips/?rev=5316&view=rev
Author:   bogdan_iancu
Date:     2009-02-14 22:42:02 +0000 (Sat, 14 Feb 2009)

Log Message:
-----------
New "profile_get_values" MI command  to list how many dialogs are up for each value  (without  runing the MI command multiple times).

Closes patch #2478793.
Contributed by Richard Revels.

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


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


From noreply at sourceforge.net  Sat Feb 14 23:42:35 2009
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat, 14 Feb 2009 22:42:35 +0000
Subject: [OpenSIPS-Devel] [ opensips-Patches-2478793 ] Allow MI command to
	return all values under a profile
Message-ID: <E1LYTDX-0006Dm-FC@3bkjzd1.ch3.sourceforge.com>

Patches item #2478793, was opened at 2008-12-31 14:25
Message generated for change (Comment added) made by bogdan_iancu
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086412&aid=2478793&group_id=232389

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: modules
>Group: trunk
>Status: Closed
Resolution: Accepted
Priority: 5
Private: No
Submitted By: Richard Revels (rrevels)
Assigned to: Bogdan-Andrei Iancu (bogdan_iancu)
Summary: Allow MI command to return all values under a profile

Initial Comment:
This is a small patch to check for the value of "all" when using the MI command profile_get_size.  We needed it for the case where we want to know how many dialogs are up for each value but did not want to have to run the MI command multiple times.

opensipsctl fifo profile_get_size inbound all


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

>Comment By: Bogdan-Andrei Iancu (bogdan_iancu)
Date: 2009-02-15 00:42

Message:
Hi Richard,

The patch is on SVN trunk.

Thanks and regards,
Bogdan

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

Comment By: Richard Revels (rrevels)
Date: 2009-01-29 05:31

Message:
Uploaded new diff file.  This was also created against 1.4 revision 5055. 
The patch should be applied after changing to the modules/dialog directory.

Usage:
opensipsctl fifo profile_get_values outbound

Will return list of values assigned to outbound profile with dialog count
in each.  Also prints summary count of all values.

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

Comment By: Richard Revels (rrevels)
Date: 2009-01-09 21:37

Message:
I thought about that and decided it wasn't a problem.  Guess I should have
thought about it a little more.  I was planning to work on an update this
weekend.  I'll change it to a new function at the same time.

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

Comment By: Bogdan-Andrei Iancu (bogdan_iancu)
Date: 2009-01-09 12:02

Message:
Hi Richard,

I agree with Ovidiu - better make a new function to avoid conflicts
between values and keyword.

Regards,
Bogdan

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

Comment By: Ovidiu Sas (osas)
Date: 2009-01-05 18:51

Message:
This patch will make 'all' a restricted value for a profile.
I would rather have a new mi command for returning all values (like
profile_get_vsize).

Regards,
Ovidiu Sas

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

Comment By: Richard Revels (rrevels)
Date: 2009-01-04 18:43

Message:
Added a second patch file which correctly returns all values within each
hash rather than just the first one.  The next step will be to have the new
function return counts rather than calling get_profile_size in a loop.

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

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


From bogdan at voice-system.ro  Sat Feb 14 23:44:37 2009
From: bogdan at voice-system.ro (Bogdan-Andrei Iancu)
Date: Sun, 15 Feb 2009 00:44:37 +0200
Subject: [OpenSIPS-Devel] Reminder: SVN freeze - 16 Feb 00:00 GMT
Message-ID: <49974955.9070507@voice-system.ro>

Hi,

SVN will be freeze (for new features) for 1.5.0 release on 16th of Feb 
00:00 GMT.  Only fixes will allowed from that point.

Regards,
Bogdan


From noreply at sourceforge.net  Sun Feb 15 10:52:29 2009
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun, 15 Feb 2009 09:52:29 +0000
Subject: [OpenSIPS-Devel] [ opensips-Feature Requests-2602256 ] Add another
	return code to handle_subscribe for pending reqs
Message-ID: <E1LYdfp-0004Um-E4@g45xhf1.ch3.sourceforge.com>

Feature Requests item #2602256, was opened at 2009-02-15 09:52
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086413&aid=2602256&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: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: Add another return code to handle_subscribe for pending reqs

Initial Comment:
(submitted by vasil.kolev at attractel.com)
(I'll create an account, I promise :) )


The attached patch makes handle_subscribe return to the routing if the request is pending. Based on this, we can relay the subscribe to the remote UA, so it can do the decision and update us in some way, as otherwise we can't really trigger it do to presence authorization.

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

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


From anca at opensips.org  Sun Feb 15 22:50:24 2009
From: anca at opensips.org (Anca Vamanu)
Date: Sun, 15 Feb 2009 21:50:24 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[5317] trunk/modules/dialplan
Message-ID: <E1LYosa-0000HQ-UF@3kljzd1.ch3.sourceforge.com>

Revision: 5317
          http://opensips.svn.sourceforge.net/opensips/?rev=5317&view=rev
Author:   anca_vamanu
Date:     2009-02-15 21:50:24 +0000 (Sun, 15 Feb 2009)

Log Message:
-----------
- included readers-writers locking mechanism to prevent against inconsistencies when reload command is called 

Modified Paths:
--------------
    trunk/modules/dialplan/dialplan.c
    trunk/modules/dialplan/dialplan.h
    trunk/modules/dialplan/dp_db.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 Feb 16 00:47:55 2009
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun, 15 Feb 2009 23:47:55 +0000
Subject: [OpenSIPS-Devel] [ opensips-Bugs-2335003 ]
	ERROR:db_mysql:db_mysql_submit_query
Message-ID: <E1LYqiJ-0006sG-2f@g45xhf1.ch3.sourceforge.com>

Bugs item #2335003, was opened at 2008-11-23 22:54
Message generated for change (Comment added) made by ibc_sf
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=2335003&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: 1
Private: No
Submitted By: I?aki Baz (ibc_sf)
Assigned to: Nobody/Anonymous (nobody)
Summary: ERROR:db_mysql:db_mysql_submit_query

Initial Comment:
This error occurs to me very often (sometimes during an INVITE, during a SUBSCRIBE...). If it occurs during an INVITE, then OpenSIPS returns 500:

-----------
Nov 23 16:42:07 [12195] ERROR:db_mysql:db_mysql_submit_query: driver error on 
query: Commands out of sync; you can't run this command now
Nov 23 16:42:07 [12195] ERROR:core:db_do_query: error while submitting query
Nov 23 16:42:07 [12195] ERROR:auth_db:get_ha1: failed to query database
-----------

I've two users registered (alice and bob), both registered in the same Twinkle sofphone.
- If alice calls (so OpenSIPS sends 407) the OpenSIPS returns 500 when alice re-sends the INVITE with credentials (auth_db issue clearly).
- If bob calls (OpenSIPS sends also 407) bob re-sends the INVITE with credentials and there is no problem.

After restarting OpenSIPS the issue dissapears (temporaly).

I've found similar problems, specially this thread:
  http://www.mail-archive.com/devel%40lists.openser.org/msg02761.html
in which Bogdan finally says:

---------
as the DB connections are TCP connections, if the connection is opened before the fork, it will inherited by all the forked child procs. This is a typical error if you mishandle a DB connection from mod_init().
---------

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

>Comment By: I?aki Baz (ibc_sf)
Date: 2009-02-16 00:47

Message:
Hi, after some days I've rechecked the logs and the error still occurs. The
server has *very low* traffic (just me when open my softphone with 3-4
accounts configured). The version I'm running now is 5190 and I attach a
log.
Note however that in this log it seems that the error is related to
presence_dialoginfo module (the PUBLISH is generated by pua_dialoginfo).
The proccess involve in the bug is 10277.
File Added: ERROR_db_mysql-rev5190.txt

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

Comment By: I?aki Baz (ibc_sf)
Date: 2009-01-21 19:40

Message:
The last error:
  ERROR:db_mysql:db_mysql_submit_query: driver error on query: Commands
out of sync; you can't run this command now
occurred in Jan 15, but I don't know which revision I was using (anyway a
modern one).

I'm compiling it against the trunk revision right now and will check. I
have full logs (level = 4) and store the logs in a file separated from
syslog so if the error occurs I'd have enough information.

I would like to tell something better but this is the best I have.

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

Comment By: Bogdan-Andrei Iancu (bogdan_iancu)
Date: 2009-01-21 14:25

Message:
Hi Inaki,

is this issue still actual after the latest presence fixes?

Regards,
Bogdan

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

Comment By: I?aki Baz (ibc_sf)
Date: 2008-12-15 20:25

Message:
After some checks I've realized that this bug is related to presence
module.

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

Comment By: I?aki Baz (ibc_sf)
Date: 2008-12-11 10:32

Message:
Sorry, forget it. The problem also occurs with "children=1".
I'm getting crazy :(

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

Comment By: I?aki Baz (ibc_sf)
Date: 2008-12-10 17:47

Message:
The ERROR just occurs when "children>1". Some tested cases:

1) OK
children=1
dissable_tcp=no
listen=MY_IP:MY_PORT

2) ERROR:db_mysql:db_mysql_submit_query
children=2
dissable_tcp=no
listen=MY_IP:MY_PORT

3) OK
children=1
dissable_tcp=no
listen=MY_IP:MY_PORT
listen=MY_IP:MY_PORT_2
listen=MY_IP_2:MY_PORT
listen=MY_IP_2:MY_PORT_2

4) ERROR:db_mysql:db_mysql_submit_query
children=2
dissable_tcp=no
listen=MY_IP:MY_PORT
listen=MY_IP:MY_PORT_2
listen=MY_IP_2:MY_PORT
listen=MY_IP_2:MY_PORT_2


This is, the error occurs VERY VERY often when "children>1", no matter how
many listening binds there are.


Also, as you can see in the following log, the error is related to the
MySQL driver, regardless of the OpenSIPS module:

---------
opensips[23846]: ERROR:db_mysql:db_mysql_submit_query: driver error on
query: Duplicate entry 'sip:bob at domain.net-bob-domain.net-presence'
for key 2
opensips[23846]: ERROR:core:db_do_insert: error while submitting query
opensips[23846]: ERROR:presence:update_presentity: inserting new
record in database
opensips[23846]: ERROR:presence:handle_publish: when updating presentity
opensips[23847]: ERROR:db_mysql:db_mysql_submit_query: driver error on
query: Commands out of sync; you can't run this command now
opensips[23847]: ERROR:core:db_do_query: error while submitting query
opensips[23847]: ERROR:presence:get_p_notify_body: failed to query
presentity table
opensips[23847]: ERROR:db_mysql:db_mysql_submit_query: driver error on
query: Commands out of sync; you can't run this command now
opensips[23847]: ERROR:core:db_do_query: error while submitting query
opensips[23847]: ERROR:auth_db:get_ha1: failed to query database
opensips[23847]: ERROR:db_mysql:db_mysql_submit_query: driver error on
query: Commands out of sync; you can't run this command now
opensips[23847]: ERROR:core:db_do_query: error while submitting query
opensips[23847]: ERROR:auth_db:get_ha1: failed to query database
opensips[23847]: ERROR:db_mysql:db_mysql_submit_query: driver error on
query: Commands out of sync; you can't run this command now
opensips[23847]: ERROR:core:db_do_delete: error while submitting query
opensips[23847]: ERROR:presence:delete_db_subs: sql delete failed
opensips[23847]: ERROR:db_mysql:db_mysql_submit_query: driver error on
query: Commands out of sync; you can't run this command now
opensips[23847]: ERROR:core:db_do_delete: error while submitting query
opensips[23847]: ERROR:presence:delete_db_subs: sql delete failed
opensips[23847]: ERROR:db_mysql:db_mysql_submit_query: driver error on
query: Commands out of sync; you can't run this command now
opensips[23847]: ERROR:core:db_do_delete: error while submitting query
opensips[23847]: ERROR:presence:delete_db_subs: sql delete failed
opensips[23847]: ERROR:db_mysql:db_mysql_submit_query: driver error on
query: Commands out of sync; you can't run this command now
opensips[23847]: ERROR:core:db_do_delete: error while submitting query
opensips[23847]: ERROR:presence:delete_db_subs: sql delete failed
opensips[23847]: ERROR:presence:update_subscription: deleting
subscription record from database
opensips[23847]: ERROR:presence:handle_subscribe: in update_subscription
opensips[23847]: ERROR:db_mysql:db_mysql_submit_query: driver error on
query: Commands out of sync; you can't run this command now
opensips[23847]: ERROR:core:db_do_delete: error while submitting query
opensips[23847]: ERROR:presence:delete_db_subs: sql delete failed
opensips[23847]: ERROR:presence:update_subscription: deleting
subscription record from database
opensips[23847]: ERROR:presence:handle_subscribe: in update_subscription
opensips[23847]: ERROR:db_mysql:db_mysql_submit_query: driver error on
query: Commands out of sync; you can't run this command now
opensips[23847]: ERROR:core:db_do_delete: error while submitting query
opensips[23847]: ERROR:presence:delete_db_subs: sql delete failed
opensips[23847]: ERROR:presence:update_subscription: deleting
subscription record from database
opensips[23847]: ERROR:presence:handle_subscribe: in update_subscription
opensips[23847]: ERROR:db_mysql:db_mysql_submit_query: driver error on
query: Commands out of sync; you can't run this command now
opensips[23847]: ERROR:core:db_do_delete: error while submitting query
opensips[23847]: ERROR:presence:delete_db_subs: sql delete failed
opensips[23847]: ERROR:presence:update_subscription: deleting
subscription record from database
opensips[23847]: ERROR:presence:handle_subscribe: in update_subscription
opensips[23847]: ERROR:db_mysql:db_mysql_submit_query: driver error on
query: Commands out of sync; you can't run this command now
opensips[23847]: ERROR:core:db_do_delete: error while submitting query
opensips[23847]: ERROR:presence:delete_db_subs: sql delete failed
opensips[23847]: ERROR:presence:update_subscription: deleting
subscription record from database
opensips[23847]: ERROR:presence:handle_subscribe: in update_subscription
opensips[23847]: ERROR:db_mysql:db_mysql_submit_query: driver error on
query: Commands out of sync; you can't run this command now
opensips[23847]: ERROR:core:db_do_delete: error while submitting query
opensips[23847]: ERROR:presence:delete_db_subs: sql delete failed
opensips[23847]: ERROR:presence:update_subscription: deleting
subscription record from database
opensips[23847]: ERROR:presence:handle_subscribe: in update_subscription
opensips[23847]: ERROR:db_mysql:db_mysql_submit_query: driver error on
query: Commands out of sync; you can't run this command now
opensips[23847]: ERROR:core:db_do_query: error while submitting query
opensips[23847]: ERROR:auth_db:get_ha1: failed to query database
opensips[23847]: ERROR:db_mysql:db_mysql_submit_query: driver error on
query: Commands out of sync; you can't run this command now
opensips[23847]: ERROR:core:db_do_query: error while submitting query
opensips[23847]: ERROR:auth_db:get_ha1: failed to query database
opensips[23847]: ERROR:db_mysql:db_mysql_submit_query: driver error on
query: Commands out of sync; you can't run this command now
opensips[23847]: ERROR:core:db_do_query: error while submitting query
opensips[23847]: ERROR:auth_db:get_ha1: failed to query database
opensips[23847]: ERROR:db_mysql:db_mysql_submit_query: driver error on
query: Commands out of sync; you can't run this command now
opensips[23847]: ERROR:core:db_do_query: error while submitting query
opensips[23847]: ERROR:auth_db:get_ha1: failed to query database
opensips[23847]: ERROR:db_mysql:db_mysql_submit_query: driver error on
query: Commands out of sync; you can't run this command now
opensips[23847]: ERROR:core:db_do_query: error while submitting query
opensips[23847]: ERROR:auth_db:get_ha1: failed to query database
----------

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

Comment By: I?aki Baz (ibc_sf)
Date: 2008-11-24 14:23

Message:
I use Debian Etch (64 bits) with OpenSIPS trunk version:

ii  libmysqlclient15-dev              5.0.32-7etch6
ii  libmysqlclient15off               5.0.32-7etch6
ii  mysql-client-5.0                  5.0.32-7etch6
ii  mysql-common                      5.0.32-7etch6
ii  mysql-server-5.0                  5.0.32-7etch6
ii  opensips-mysql-module             1.4.0-1

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

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


From noreply at sourceforge.net  Mon Feb 16 17:37:48 2009
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 16 Feb 2009 16:37:48 +0000
Subject: [OpenSIPS-Devel] [ opensips-Bugs-2593088 ] Crash with db_postgres
	and presence
Message-ID: <E1LZ6Tc-0007XH-7D@665xhf1.ch3.sourceforge.com>

Bugs item #2593088, was opened at 2009-02-12 15:48
Message generated for change (Comment added) made by anca_vamanu
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=2593088&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: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: Crash with db_postgres and presence

Initial Comment:
(submitted by vasil.kolev at attractel.com)

The problem is as follows - a query is executed, but for some reason the results from the previous one are read back from the DB driver, which in turn makes opensips to crash as the number of columns is lower and it tries to dereference stuff that doesn't exist.

Appended are the log and the backtrace:


Feb 12 13:42:59 f-ast2 opensips[29504]: DBG:db_postgres:db_postgres_submit_query: 0x8197240 PQsendQuery(select status,reason from watchers where presentity_uri='sip:bbb%40ccc.com at 10.2.30.5' AND watcher_username='aaa%40ccc.com' AND watcher_domain='10.2.30.5' AND event='presence') 
Feb 12 13:42:59 f-ast2 opensips[29504]: DBG:core:db_new_result: allocate 28 bytes for result set at 0x81a0948 
Feb 12 13:42:59 f-ast2 opensips[29504]: DBG:db_postgres:db_postgres_store_result: 0x8197240 PQresultStatus(PGRES_TUPLES_OK) PQgetResult(0x94c0300) 
Feb 12 13:42:59 f-ast2 opensips[29504]: DBG:db_postgres:db_postgres_get_columns: 1 columns returned from the query 
Feb 12 13:42:59 f-ast2 opensips[29504]: DBG:core:db_allocate_columns: allocate 16 bytes for result columns at 0x819ecd0 
Feb 12 13:42:59 f-ast2 opensips[29504]: DBG:db_postgres:db_postgres_get_columns: RES_NAMES(0x819ecd8)[0]=[username] 
Feb 12 13:42:59 f-ast2 opensips[29504]: DBG:db_postgres:db_postgres_get_columns: use DB_STRING result type 
Feb 12 13:42:59 f-ast2 opensips[29504]: DBG:db_postgres:db_postgres_convert_rows: allocate for 1 columns 4 bytes in row buffer at 0x819d5b8 
Feb 12 13:42:59 f-ast2 opensips[29504]: DBG:core:db_allocate_rows: allocate 28 bytes for result rows and values at 0x819f870 
Feb 12 13:42:59 f-ast2 opensips[29504]: DBG:db_postgres:db_postgres_convert_rows: PQgetvalue(0x8197240,0,0)=[aaa at ccc.com] 
Feb 12 13:42:59 f-ast2 opensips[29504]: DBG:db_postgres:db_postgres_convert_rows: allocated 11 bytes for row_buf[0] at 0x819d5c8 
Feb 12 13:42:59 f-ast2 opensips[29504]: DBG:db_postgres:db_postgres_convert_rows: [0][0] Column[username]=[aaa at ccc.com] 
Feb 12 13:42:59 f-ast2 opensips[29504]: DBG:db_postgres:db_postgres_str2val: converting STRING [aaa at ccc.com] 
Feb 12 13:42:59 f-ast2 opensips[29504]: DBG:db_postgres:db_postgres_convert_rows: freeing row buffer at 0x819d5b8 
Feb 12 13:42:59 f-ast2 opensips[29504]: DBG:db_postgres:free_query: PQclear(0x94c0300) result set 
Feb 12 13:42:59 f-ast2 opensips[29507]: DBG:db_postgres:db_postgres_store_result: 0x8197100 PQresultStatus(PGRES_TUPLES_OK) PQgetResult(0x94bb108) 
Feb 12 13:42:59 f-ast2 kernel: [842163.893756] opensips[29504]: segfault at 1 ip b77b98c6 sp bff1ab30 error 4 in presence.so[b7790000+31000]



Core was generated by `opensips'.
Program terminated with signal 11, Segmentation fault.
[New process 29504]
#0  0xb77b98c6 in get_db_subs_auth (subs=0xbff1acf4, found=0xbff1ad94) at subscribe.c:1980
1980			subs->reason.len= strlen(row_vals[1].val.string_val);
(gdb) bt
#0  0xb77b98c6 in get_db_subs_auth (subs=0xbff1acf4, found=0xbff1ad94) at subscribe.c:1980
#1  0xb77ba5cc in handle_subscribe (msg=0x819acb8, str1=0x0, str2=0x0) at subscribe.c:630
#2  0x08055591 in do_action (a=0x8195940, msg=0x819acb8) at action.c:961
#3  0x080541e2 in run_action_list (a=0x8195940, msg=0x819acb8) at action.c:139
#4  0x08056ecd in do_action (a=0x8195fe0, msg=0x819acb8) at action.c:705
#5  0x080541e2 in run_action_list (a=0x8195fe0, msg=0x819acb8) at action.c:139
#6  0x08057529 in do_action (a=0x8196048, msg=0x819acb8) at action.c:711
#7  0x080541e2 in run_action_list (a=0x81953d0, msg=0x819acb8) at action.c:139
#8  0x08056914 in do_action (a=0x8192808, msg=0x819acb8) at action.c:119
#9  0x080541e2 in run_action_list (a=0x8192808, msg=0x819acb8) at action.c:139
#10 0x08056ecd in do_action (a=0x8192870, msg=0x819acb8) at action.c:705
#11 0x080541e2 in run_action_list (a=0x818d6b8, msg=0x819acb8) at action.c:139
#12 0x08057ee1 in run_top_route (a=0x818d6b8, msg=0x819acb8) at action.c:119
#13 0x0809228c in receive_msg (
    buf=0x8164100 "SUBSCRIBE sip:bbb%40ccc.com at 10.2.30.5;transport=UDP SIP/2.0\r\nVia: SIP/2.0/UDP 10.2.2.179:5060;branch=z9hG4bK-d8754z-1c3f735ee1e02d36-1---d8754z-\r\nMax-Forwards: 69\r\nContact: <sip:aaa%40ccc.com at 10.2.2.1"..., len=793, rcv_info=0xbff1bad4) at receive.c:165
#14 0x080cdf4b in udp_rcv_loop () at udp_server.c:449
#15 0x0806c3af in main (argc=1, argv=0xbff1bc64) at main.c:778



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

>Comment By: Anca Vamanu (anca_vamanu)
Date: 2009-02-16 18:37

Message:
Hi Vasil,

Thank you for the report.
It seems that the problem is another one - not what you described.

From noreply at sourceforge.net  Mon Feb 16 17:38:23 2009
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 16 Feb 2009 16:38:23 +0000
Subject: [OpenSIPS-Devel] [ opensips-Bugs-2591935 ] Error in sending NOTIFY
	for PUBLISH in RLS mode
Message-ID: <E1LZ6UB-0002xU-BT@cdv4jf1.ch3.sourceforge.com>

Bugs item #2591935, was opened at 2009-02-12 08:31
Message generated for change (Settings changed) made by anca_vamanu
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=2591935&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: Nathan (rmnathan)
>Assigned to: Anca Vamanu (anca_vamanu)
Summary: Error in sending NOTIFY for PUBLISH in RLS mode

Initial Comment:
Hi
When opensips got publish for the user(say E1_1) which has in two list subscriptions, it is sending notify to one user only.
For example:
UE2_1 list will have 2 entry uri like E1_1,E1_2
UE2_2 list will have 2 entry uri like E1_2,E1_1

S2_1 subscribe to UE2_1
S2_2 subscribe to UE2_2
If E1_1 send publish, opensips sends notify to S2_1 only. But it should send notify to S2_2 too.

Please find the attached pcap file for detailed call flow.

Regards,
rmnathan


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

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


From noreply at sourceforge.net  Mon Feb 16 17:56:14 2009
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 16 Feb 2009 16:56:14 +0000
Subject: [OpenSIPS-Devel] [ opensips-Bugs-2593088 ] Crash with db_postgres
	and presence
Message-ID: <E1LZ6lS-000513-67@g45xhf1.ch3.sourceforge.com>

Bugs item #2593088, was opened at 2009-02-12 13:48
Message generated for change (Comment added) made by nobody
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=2593088&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: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: Crash with db_postgres and presence

Initial Comment:
(submitted by vasil.kolev at attractel.com)

The problem is as follows - a query is executed, but for some reason the results from the previous one are read back from the DB driver, which in turn makes opensips to crash as the number of columns is lower and it tries to dereference stuff that doesn't exist.

Appended are the log and the backtrace:


Feb 12 13:42:59 f-ast2 opensips[29504]: DBG:db_postgres:db_postgres_submit_query: 0x8197240 PQsendQuery(select status,reason from watchers where presentity_uri='sip:bbb%40ccc.com at 10.2.30.5' AND watcher_username='aaa%40ccc.com' AND watcher_domain='10.2.30.5' AND event='presence') 
Feb 12 13:42:59 f-ast2 opensips[29504]: DBG:core:db_new_result: allocate 28 bytes for result set at 0x81a0948 
Feb 12 13:42:59 f-ast2 opensips[29504]: DBG:db_postgres:db_postgres_store_result: 0x8197240 PQresultStatus(PGRES_TUPLES_OK) PQgetResult(0x94c0300) 
Feb 12 13:42:59 f-ast2 opensips[29504]: DBG:db_postgres:db_postgres_get_columns: 1 columns returned from the query 
Feb 12 13:42:59 f-ast2 opensips[29504]: DBG:core:db_allocate_columns: allocate 16 bytes for result columns at 0x819ecd0 
Feb 12 13:42:59 f-ast2 opensips[29504]: DBG:db_postgres:db_postgres_get_columns: RES_NAMES(0x819ecd8)[0]=[username] 
Feb 12 13:42:59 f-ast2 opensips[29504]: DBG:db_postgres:db_postgres_get_columns: use DB_STRING result type 
Feb 12 13:42:59 f-ast2 opensips[29504]: DBG:db_postgres:db_postgres_convert_rows: allocate for 1 columns 4 bytes in row buffer at 0x819d5b8 
Feb 12 13:42:59 f-ast2 opensips[29504]: DBG:core:db_allocate_rows: allocate 28 bytes for result rows and values at 0x819f870 
Feb 12 13:42:59 f-ast2 opensips[29504]: DBG:db_postgres:db_postgres_convert_rows: PQgetvalue(0x8197240,0,0)=[aaa at ccc.com] 
Feb 12 13:42:59 f-ast2 opensips[29504]: DBG:db_postgres:db_postgres_convert_rows: allocated 11 bytes for row_buf[0] at 0x819d5c8 
Feb 12 13:42:59 f-ast2 opensips[29504]: DBG:db_postgres:db_postgres_convert_rows: [0][0] Column[username]=[aaa at ccc.com] 
Feb 12 13:42:59 f-ast2 opensips[29504]: DBG:db_postgres:db_postgres_str2val: converting STRING [aaa at ccc.com] 
Feb 12 13:42:59 f-ast2 opensips[29504]: DBG:db_postgres:db_postgres_convert_rows: freeing row buffer at 0x819d5b8 
Feb 12 13:42:59 f-ast2 opensips[29504]: DBG:db_postgres:free_query: PQclear(0x94c0300) result set 
Feb 12 13:42:59 f-ast2 opensips[29507]: DBG:db_postgres:db_postgres_store_result: 0x8197100 PQresultStatus(PGRES_TUPLES_OK) PQgetResult(0x94bb108) 
Feb 12 13:42:59 f-ast2 kernel: [842163.893756] opensips[29504]: segfault at 1 ip b77b98c6 sp bff1ab30 error 4 in presence.so[b7790000+31000]



Core was generated by `opensips'.
Program terminated with signal 11, Segmentation fault.
[New process 29504]
#0  0xb77b98c6 in get_db_subs_auth (subs=0xbff1acf4, found=0xbff1ad94) at subscribe.c:1980
1980			subs->reason.len= strlen(row_vals[1].val.string_val);
(gdb) bt
#0  0xb77b98c6 in get_db_subs_auth (subs=0xbff1acf4, found=0xbff1ad94) at subscribe.c:1980
#1  0xb77ba5cc in handle_subscribe (msg=0x819acb8, str1=0x0, str2=0x0) at subscribe.c:630
#2  0x08055591 in do_action (a=0x8195940, msg=0x819acb8) at action.c:961
#3  0x080541e2 in run_action_list (a=0x8195940, msg=0x819acb8) at action.c:139
#4  0x08056ecd in do_action (a=0x8195fe0, msg=0x819acb8) at action.c:705
#5  0x080541e2 in run_action_list (a=0x8195fe0, msg=0x819acb8) at action.c:139
#6  0x08057529 in do_action (a=0x8196048, msg=0x819acb8) at action.c:711
#7  0x080541e2 in run_action_list (a=0x81953d0, msg=0x819acb8) at action.c:139
#8  0x08056914 in do_action (a=0x8192808, msg=0x819acb8) at action.c:119
#9  0x080541e2 in run_action_list (a=0x8192808, msg=0x819acb8) at action.c:139
#10 0x08056ecd in do_action (a=0x8192870, msg=0x819acb8) at action.c:705
#11 0x080541e2 in run_action_list (a=0x818d6b8, msg=0x819acb8) at action.c:139
#12 0x08057ee1 in run_top_route (a=0x818d6b8, msg=0x819acb8) at action.c:119
#13 0x0809228c in receive_msg (
    buf=0x8164100 "SUBSCRIBE sip:bbb%40ccc.com at 10.2.30.5;transport=UDP SIP/2.0\r\nVia: SIP/2.0/UDP 10.2.2.179:5060;branch=z9hG4bK-d8754z-1c3f735ee1e02d36-1---d8754z-\r\nMax-Forwards: 69\r\nContact: <sip:aaa%40ccc.com at 10.2.2.1"..., len=793, rcv_info=0xbff1bad4) at receive.c:165
#14 0x080cdf4b in udp_rcv_loop () at udp_server.c:449
#15 0x0806c3af in main (argc=1, argv=0xbff1bc64) at main.c:778



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

Comment By: Nobody/Anonymous (nobody)
Date: 2009-02-16 16:56

Message:
Anca, that's not the problem, if you get a NULL in the column, it's still
two columns (I specifically checked the code).

Also, I've seen in the logs how one query is executed and another thread
takes the result, I'm definitely sure this is the problem (logs are at the
end of the message). The solution I proposed sucks and somewhat works, and
you're about to release 1.5, but when I have some time I have some initial
approval for writing a better DB pool infrastructure for OpenSIPS (and
contributing it), so I'll probably send a proposal to the list next week.

As for the log - PID 29507 does a query and while waiting for the result,
29504 does another query and gets the result of 29507's query, and crashes
(the result is obviously the wrong one, the column is called "username").


Feb 12 13:42:59 f-ast2 opensips[29507]:
DBG:db_postgres:db_postgres_val2str: PQescapeStringConn: in: 11 chars, out:
11 chars 
Feb 12 13:42:59 f-ast2 opensips[29507]:
DBG:db_postgres:db_postgres_val2str: PQescapeStringConn: in: 9 chars, out:
9 chars 
Feb 12 13:42:59 f-ast2 opensips[29507]:
DBG:db_postgres:db_postgres_val2str: PQescapeStringConn: in: 13 chars, out:
13 chars 
Feb 12 13:42:59 f-ast2 opensips[29507]:
DBG:db_postgres:db_postgres_submit_query: 0x8197100 PQsendQuery(select
username from uri where username='aaa at ccc.com' AND domain='10.2.30.5' AND
uri_user='aaa%40ccc.
com') 
Feb 12 13:42:59 f-ast2 opensips[29507]: DBG:core:db_new_result: allocate
28 bytes for result set at 0x81a1c70 
Feb 12 13:42:59 f-ast2 opensips[29504]:
DBG:db_postgres:db_postgres_store_result: 0x81971a8
PQresultStatus(PGRES_TUPLES_OK) PQgetResult(0x94c0300) 
Feb 12 13:42:59 f-ast2 opensips[29504]:
DBG:db_postgres:db_postgres_get_columns: 2 columns returned from the query

Feb 12 13:42:59 f-ast2 opensips[29504]: DBG:core:db_allocate_columns:
allocate 32 bytes for result columns at 0x81a0410 
Feb 12 13:42:59 f-ast2 opensips[29504]:
DBG:db_postgres:db_postgres_get_columns: RES_NAMES(0x81a0420)[0]=[password]

Feb 12 13:42:59 f-ast2 opensips[29504]:
DBG:db_postgres:db_postgres_get_columns: use DB_STRING result type 
Feb 12 13:42:59 f-ast2 opensips[29504]:
DBG:db_postgres:db_postgres_get_columns: RES_NAMES(0x81a0428)[1]=[rpid] 
Feb 12 13:42:59 f-ast2 opensips[29504]:
DBG:db_postgres:db_postgres_get_columns: use DB_STRING result type 
Feb 12 13:42:59 f-ast2 opensips[29504]:
DBG:db_postgres:db_postgres_convert_rows: allocate for 2 columns 8 bytes in
row buffer at 0x819ba10 
Feb 12 13:42:59 f-ast2 opensips[29504]: DBG:core:db_allocate_rows:
allocate 48 bytes for result rows and values at 0x819dfe8 
Feb 12 13:42:59 f-ast2 opensips[29504]:
DBG:db_postgres:db_postgres_convert_rows: PQgetvalue(0x81971a8,0,0)=[1234]

Feb 12 13:42:59 f-ast2 opensips[29504]:
DBG:db_postgres:db_postgres_convert_rows: allocated 4 bytes for row_buf[0]
at 0x819c5a0 
Feb 12 13:42:59 f-ast2 opensips[29504]:
DBG:db_postgres:db_postgres_convert_rows: [0][0] Column[password]=[1234] 
Feb 12 13:42:59 f-ast2 opensips[29504]:
DBG:db_postgres:db_postgres_convert_rows: PQgetvalue(0x81971a8,0,1)=[] 
Feb 12 13:42:59 f-ast2 opensips[29504]:
DBG:db_postgres:db_postgres_convert_rows: allocated 0 bytes for row_buf[1]
at 0x819c5b0 
Feb 12 13:42:59 f-ast2 opensips[29504]:
DBG:db_postgres:db_postgres_convert_rows: [0][1] Column[rpid]=[] 
Feb 12 13:42:59 f-ast2 opensips[29504]:
DBG:db_postgres:db_postgres_str2val: converting STRING [1234] 
Feb 12 13:42:59 f-ast2 opensips[29504]:
DBG:db_postgres:db_postgres_str2val: converting STRING [] 
Feb 12 13:42:59 f-ast2 opensips[29504]:
DBG:db_postgres:db_postgres_convert_rows: freeing row buffer at 0x819ba10 
Feb 12 13:42:59 f-ast2 opensips[29504]: DBG:db_postgres:free_query:
PQclear(0x94c0300) result set 
Feb 12 13:42:59 f-ast2 opensips[29504]: DBG:auth_db:get_ha1: HA1 string
calculated: 7469b80fecb342ef7a4b4daeff01fc57 
Feb 12 13:42:59 f-ast2 opensips[29504]: DBG:auth:check_response: our
result = 'fadac954de8faf7fcb91f593cab55ec6' 
Feb 12 13:42:59 f-ast2 opensips[29504]: DBG:auth:check_response:
authorization is OK 
Feb 12 13:42:59 f-ast2 opensips[29504]: DBG:auth:post_auth: nonce index=
46 
Feb 12 13:42:59 f-ast2 opensips[29504]: DBG:core:db_free_columns: freeing
result columns at 0x81a0410 
Feb 12 13:42:59 f-ast2 opensips[29504]: DBG:core:db_free_rows: freeing 1
rows 
Feb 12 13:42:59 f-ast2 opensips[29504]: DBG:core:db_free_rows: freeing
rows at 0x819dfe8 
Feb 12 13:42:59 f-ast2 opensips[29504]: DBG:core:db_free_result: freeing
result set at 0x81a0970 
Feb 12 13:42:59 f-ast2 opensips[29504]:
DBG:db_postgres:db_postgres_val2str: PQescapeStringConn: in: 11 chars, out:
11 chars 
Feb 12 13:42:59 f-ast2 opensips[29504]:
DBG:db_postgres:db_postgres_val2str: PQescapeStringConn: in: 9 chars, out:
9 chars 
Feb 12 13:42:59 f-ast2 opensips[29504]:
DBG:db_postgres:db_postgres_val2str: PQescapeStringConn: in: 13 chars, out:
13 chars 
Feb 12 13:42:59 f-ast2 opensips[29504]:
DBG:db_postgres:db_postgres_submit_query: 0x8197100 PQsendQuery(select
username from uri where username='aaa at ccc.com' AND domain='10.2.30.5' AND
uri_user='aaa%40ccc.
com') 
Feb 12 13:42:59 f-ast2 opensips[29504]: DBG:core:db_new_result: allocate
28 bytes for result set at 0x81a0970 
Feb 12 13:42:59 f-ast2 opensips[29504]:
DBG:db_postgres:db_postgres_store_result: 0x8197100
PQresultStatus(PGRES_TUPLES_OK) PQgetResult(0x94bb108) 
Feb 12 13:42:59 f-ast2 opensips[29504]:
DBG:db_postgres:db_postgres_get_columns: 1 columns returned from the query

Feb 12 13:42:59 f-ast2 opensips[29504]: DBG:core:db_allocate_columns:
allocate 16 bytes for result columns at 0x819ba10 
Feb 12 13:42:59 f-ast2 opensips[29504]:
DBG:db_postgres:db_postgres_get_columns: RES_NAMES(0x819ba18)[0]=[username]

Feb 12 13:42:59 f-ast2 opensips[29504]:
DBG:db_postgres:db_postgres_get_columns: use DB_STRING result type 
Feb 12 13:42:59 f-ast2 opensips[29504]:
DBG:db_postgres:db_postgres_convert_rows: allocate for 1 columns 4 bytes in
row buffer at 0x819cfe8 
Feb 12 13:42:59 f-ast2 opensips[29504]: DBG:core:db_allocate_rows:
allocate 28 bytes for result rows and values at 0x81a0410 
Feb 12 13:42:59 f-ast2 opensips[29504]:
DBG:db_postgres:db_postgres_convert_rows:
PQgetvalue(0x8197100,0,0)=[aaa at ccc.com] 
Feb 12 13:42:59 f-ast2 opensips[29504]:
DBG:db_postgres:db_postgres_convert_rows: allocated 11 bytes for row_buf[0]
at 0x819c9e8 
Feb 12 13:42:59 f-ast2 opensips[29504]:
DBG:db_postgres:db_postgres_convert_rows: [0][0]
Column[username]=[aaa at ccc.com] 
Feb 12 13:42:59 f-ast2 opensips[29504]:
DBG:db_postgres:db_postgres_str2val: converting STRING [aaa at ccc.com] 
Feb 12 13:42:59 f-ast2 opensips[29504]:
DBG:db_postgres:db_postgres_convert_rows: freeing row buffer at 0x819cfe8 
Feb 12 13:42:59 f-ast2 opensips[29504]: DBG:db_postgres:free_query:
PQclear(0x94bb108) result set 
Feb 12 13:42:59 f-ast2 opensips[29504]: DBG:uri_db:check_username: From/To
user 'aaa%40ccc.com' and auth user match 
Feb 12 13:42:59 f-ast2 opensips[29504]: DBG:core:db_free_columns: freeing
result columns at 0x819ba10 
Feb 12 13:42:59 f-ast2 opensips[29504]: DBG:core:db_free_rows: freeing 1
rows 
Feb 12 13:42:59 f-ast2 opensips[29504]: DBG:core:db_free_rows: freeing
rows at 0x81a0410 
Feb 12 13:42:59 f-ast2 opensips[29504]: DBG:core:db_free_result: freeing
result set at 0x81a0970 
Feb 12 13:42:59 f-ast2 opensips[29504]: DBG:core:grep_sock_info: checking
if host==us: 9==9 &&  [10.2.30.5] == [10.2.30.5] 
Feb 12 13:42:59 f-ast2 opensips[29504]: DBG:core:grep_sock_info: checking
if port 5060 matches port 5060 
Feb 12 13:42:59 f-ast2 opensips[29504]: DBG:tm:t_newtran: transaction on
entrance=(nil) 
Feb 12 13:42:59 f-ast2 opensips[29504]: DBG:core:parse_headers:
flags=ffffffffffffffff 
Feb 12 13:42:59 f-ast2 opensips[29504]: DBG:core:get_hdr_field:
content_length=0 
Feb 12 13:42:59 f-ast2 opensips[29504]: DBG:core:get_hdr_field: found end
of header 
Feb 12 13:42:59 f-ast2 opensips[29504]: DBG:core:parse_headers: flags=78 
Feb 12 13:42:59 f-ast2 opensips[29504]: DBG:tm:t_lookup_request: start
searching: hash=42272, isACK=0 
Feb 12 13:42:59 f-ast2 opensips[29504]: DBG:tm:matching_3261: RFC3261
transaction matching failed 
Feb 12 13:42:59 f-ast2 opensips[29504]: DBG:tm:t_lookup_request: no
transaction found 
Feb 12 13:42:59 f-ast2 opensips[29504]: DBG:tm:run_reqin_callbacks:
trans=0xb5899c08, callback type 1, id 1 entered 
Feb 12 13:42:59 f-ast2 opensips[29504]: DBG:dialog:build_new_dlg: new
dialog 0xb58be478
(c=YjQxOTNkMmM0ZWY0NTA0ZDdkMmVjMmEyODBjN2U5MDg.,f=sip:aaa%40ccc.com at 10.2.30.5;transport=UDP,t=sip:bbb%40ccc.com at 10.2.30.5;transport=UDP,ft=3d0afe4a)
on hash 864 
Feb 12 13:42:59 f-ast2 opensips[29504]: DBG:core:parse_headers: flags=20 
Feb 12 13:42:59 f-ast2 opensips[29504]: DBG:core:parse_headers: flags=400

Feb 12 13:42:59 f-ast2 opensips[29504]: DBG:dialog:populate_leg_info:
route_set , contact sip:aaa%40ccc.com at 10.2.2.179:5060, cseq 2 and bind_addr
udp:10.2.30.5:5060 
Feb 12 13:42:59 f-ast2 opensips[29504]: DBG:dialog:link_dlg: ref dlg
0xb58be478 with 3 -> 3 
Feb 12 13:42:59 f-ast2 opensips[29504]: DBG:dialog:run_create_callbacks:
dialog=0xb58be478 
Feb 12 13:42:59 f-ast2 opensips[29504]: DBG:dialog:get_dlg_timeout:
invalid AVP value, use default timeout 
Feb 12 13:42:59 f-ast2 opensips[29504]: DBG:tm:run_reqin_callbacks:
trans=0xb5899c08, callback type 1, id 0 entered 
Feb 12 13:42:59 f-ast2 opensips[29504]: DBG:core:parse_headers:
flags=ffffffffffffffff 
Feb 12 13:42:59 f-ast2 opensips[29504]: DBG:presence:search_event: start
event= [presence] 
Feb 12 13:42:59 f-ast2 opensips[29504]: DBG:presence:extract_sdialog_info:
'Expires' header found, value= 60 
Feb 12 13:42:59 f-ast2 opensips[29504]: DBG:presence:extract_sdialog_info:
'To' header ALREADY PARSED: <sip:bbb%40ccc.com at 10.2.30.5;transport=UDP> 
Feb 12 13:42:59 f-ast2 opensips[29504]: DBG:presence:extract_sdialog_info:
initial request 
Feb 12 13:42:59 f-ast2 opensips[29504]: DBG:presence:extract_sdialog_info:
subs->contact= sip:aaa%40ccc.com at 10.2.2.179:5060 - len = 33 
Feb 12 13:42:59 f-ast2 opensips[29504]:
DBG:db_postgres:db_postgres_val2str: PQescapeStringConn: in: 27 chars, out:
27 chars 
Feb 12 13:42:59 f-ast2 opensips[29504]:
DBG:db_postgres:db_postgres_val2str: PQescapeStringConn: in: 13 chars, out:
13 chars 
Feb 12 13:42:59 f-ast2 opensips[29504]:
DBG:db_postgres:db_postgres_val2str: PQescapeStringConn: in: 9 chars, out:
9 chars 
Feb 12 13:42:59 f-ast2 opensips[29504]:
DBG:db_postgres:db_postgres_val2str: PQescapeStringConn: in: 8 chars, out:
8 chars 
Feb 12 13:42:59 f-ast2 opensips[29504]:
DBG:db_postgres:db_postgres_submit_query: 0x8197240 PQsendQuery(select
status,reason from watchers where
presentity_uri='sip:bbb%40ccc.com at 10.2.30.5' AND
watcher_username='aaa%40ccc.com' AND watcher_domain='10.2.30.5' AND
event='presence') 
Feb 12 13:42:59 f-ast2 opensips[29504]: DBG:core:db_new_result: allocate
28 bytes for result set at 0x81a0948 
Feb 12 13:42:59 f-ast2 opensips[29504]:
DBG:db_postgres:db_postgres_store_result: 0x8197240
PQresultStatus(PGRES_TUPLES_OK) PQgetResult(0x94c0300) 
Feb 12 13:42:59 f-ast2 opensips[29504]:
DBG:db_postgres:db_postgres_get_columns: 1 columns returned from the query

Feb 12 13:42:59 f-ast2 opensips[29504]: DBG:core:db_allocate_columns:
allocate 16 bytes for result columns at 0x819ecd0 
Feb 12 13:42:59 f-ast2 opensips[29504]:
DBG:db_postgres:db_postgres_get_columns: RES_NAMES(0x819ecd8)[0]=[username]

Feb 12 13:42:59 f-ast2 opensips[29504]:
DBG:db_postgres:db_postgres_get_columns: use DB_STRING result type 
Feb 12 13:42:59 f-ast2 opensips[29504]:
DBG:db_postgres:db_postgres_convert_rows: allocate for 1 columns 4 bytes in
row buffer at 0x819d5b8 
Feb 12 13:42:59 f-ast2 opensips[29504]: DBG:core:db_allocate_rows:
allocate 28 bytes for result rows and values at 0x819f870 
Feb 12 13:42:59 f-ast2 opensips[29504]:
DBG:db_postgres:db_postgres_convert_rows:
PQgetvalue(0x8197240,0,0)=[aaa at ccc.com] 
Feb 12 13:42:59 f-ast2 opensips[29504]:
DBG:db_postgres:db_postgres_convert_rows: allocated 11 bytes for row_buf[0]
at 0x819d5c8 
Feb 12 13:42:59 f-ast2 opensips[29504]:
DBG:db_postgres:db_postgres_convert_rows: [0][0]
Column[username]=[aaa at ccc.com] 
Feb 12 13:42:59 f-ast2 opensips[29504]:
DBG:db_postgres:db_postgres_str2val: converting STRING [aaa at ccc.com] 
Feb 12 13:42:59 f-ast2 opensips[29504]:
DBG:db_postgres:db_postgres_convert_rows: freeing row buffer at 0x819d5b8 
Feb 12 13:42:59 f-ast2 opensips[29504]: DBG:db_postgres:free_query:
PQclear(0x94c0300) result set 
Feb 12 13:42:59 f-ast2 opensips[29507]:
DBG:db_postgres:db_postgres_store_result: 0x8197100
PQresultStatus(PGRES_TUPLES_OK) PQgetResult(0x94bb108) 
Feb 12 13:42:59 f-ast2 kernel: [842163.893756] opensips[29504]: segfault
at 1 ip b77b98c6 sp bff1ab30 error 4 in presence.so[b7790000+31000]
Feb 12 13:42:59 f-ast2 opensips[29507]:
DBG:db_postgres:db_postgres_get_columns: 2 columns returned from the query

Feb 12 13:42:59 f-ast2 opensips[29507]: DBG:core:db_allocate_columns:
allocate 32 bytes for result columns at 0x819d518 


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

Comment By: Anca Vamanu (anca_vamanu)
Date: 2009-02-16 16:37

Message:
Hi Vasil,

Thank you for the report.
It seems that the problem is another one - not what you described.

From bogdan at voice-system.ro  Mon Feb 16 18:42:04 2009
From: bogdan at voice-system.ro (Bogdan-Andrei Iancu)
Date: Mon, 16 Feb 2009 17:42:04 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[5318] trunk/modules/drouting
Message-ID: <E1LZ7To-0001BV-9O@bj8yhf1.ch3.sourceforge.com>

Revision: 5318
          http://opensips.svn.sourceforge.net/opensips/?rev=5318&view=rev
Author:   bogdan_iancu
Date:     2009-02-16 17:42:04 +0000 (Mon, 16 Feb 2009)

Log Message:
-----------
typo fixed in docs

Modified Paths:
--------------
    trunk/modules/drouting/README
    trunk/modules/drouting/doc/drouting_admin.xml


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


From bogdan at voice-system.ro  Mon Feb 16 23:20:19 2009
From: bogdan at voice-system.ro (Bogdan-Andrei Iancu)
Date: Mon, 16 Feb 2009 22:20:19 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[5319] trunk/packaging/debian
Message-ID: <E1LZBp5-0003UK-UQ@dn4whf1.ch3.sourceforge.com>

Revision: 5319
          http://opensips.svn.sourceforge.net/opensips/?rev=5319&view=rev
Author:   bogdan_iancu
Date:     2009-02-16 22:20:19 +0000 (Mon, 16 Feb 2009)

Log Message:
-----------
- added all new presence related module into opensips-presence package

Modified Paths:
--------------
    trunk/packaging/debian/rules
    trunk/packaging/debian-etch/rules
    trunk/packaging/debian-sarge/rules


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


From bogdan at voice-system.ro  Mon Feb 16 23:22:51 2009
From: bogdan at voice-system.ro (Bogdan-Andrei Iancu)
Date: Mon, 16 Feb 2009 22:22:51 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[5320]
	branches/1.4/packaging/debian
Message-ID: <E1LZBrX-0003Wl-CB@dn4whf1.ch3.sourceforge.com>

Revision: 5320
          http://opensips.svn.sourceforge.net/opensips/?rev=5320&view=rev
Author:   bogdan_iancu
Date:     2009-02-16 22:22:49 +0000 (Mon, 16 Feb 2009)

Log Message:
-----------
- RLS module added to the opensips-presence deb package

Modified Paths:
--------------
    branches/1.4/packaging/debian/rules
    branches/1.4/packaging/debian-etch/rules
    branches/1.4/packaging/debian-sarge/rules


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


From ibc at aliax.net  Tue Feb 17 00:41:28 2009
From: ibc at aliax.net (=?utf-8?q?I=C3=B1aki_Baz_Castillo?=)
Date: Tue, 17 Feb 2009 00:41:28 +0100
Subject: [OpenSIPS-Devel] Is it possible to commit new "regex" module before
	1.5?
Message-ID: <200902170041.29072.ibc@aliax.net>

Hi, I planned to commit a new module called "Regex" in SVN trunk but I was 
away these last days and couldn't submit it before the SVN freeze 
(yesterday).

I know that no new code should be submitted in this moment, but this module is 
already tested and working in Kamailio (and of course I've also checked it in 
OpenSIPS trunk version). For now there are no bugs/issues with it.

Would you, developers, accept this module now or should I wait until 1.5 is 
released?

Thanks and best regards.


PD: Regex module documentation in Kamailio:
      http://kamailio.org/docs/modules/devel/regex.html

-- 
I?aki Baz Castillo


From jh at tutpro.com  Tue Feb 17 06:19:10 2009
From: jh at tutpro.com (Juha Heinanen)
Date: Tue, 17 Feb 2009 07:19:10 +0200
Subject: [OpenSIPS-Devel] common-policy.xsd not found after openxcap upgrade
Message-ID: <18842.18638.444872.453710@tutpro.com>

i upgraded openxcap on debian lenny from version 1.0.6 to 1.0.7 using
.deb package.  after upgrade, openxcap server does not start, because
common-policy.xsd file is not found:

Starting OpenXCAP 1.0.6
Supported Root URIs: http://xcap.tutpro.com/xcap-root
Traceback (most recent call last):
  File "/usr/bin/openxcap", line 55, in <module>
    from xcap.server import XCAPServer
  File "/usr/lib/python2.5/site-packages/xcap/server.py", line 17, in <module>
  File "/usr/lib/python2.5/site-packages/xcap/authentication.py", line 22, in <module>
  File "/usr/lib/python2.5/site-packages/xcap/appusage/__init__.py", line 523, in <module>
  File "/usr/lib/python2.5/site-packages/xcap/appusage/__init__.py", line 68, in __init__
IOError: [Errno 2] No such file or directory: '/usr/lib/python2.5/site-packages/xcap/appusage/../xml-schemas/common-policy.xsd'

the link is there, but it points to wrong location:

/usr/lib/python2.5/site-packages/xcap/xml-schemas# ls -ls
total 0
0 lrwxrwxrwx 1 root root 54 2008-09-09 17:18 common-policy.xsd -> /usr/share/pyshared/xcap/xml-schemas/common-policy.xsd

openxcap package installs the file in 

# dpkg -L openxcap | egrep common-policy.xsd
/usr/share/python-support/openxcap/xcap/xml-schemas/common-policy.xsd

-- juha


From noreply at sourceforge.net  Tue Feb 17 07:02:40 2009
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 17 Feb 2009 06:02:40 +0000
Subject: [OpenSIPS-Devel] [ opensips-Bugs-2608188 ] OpenSIPS latest trunk
	libmysqlclient segfault
Message-ID: <E1LZJ2W-0001xl-Vj@d45xhf1.ch3.sourceforge.com>

Bugs item #2608188, was opened at 2009-02-17 11:47
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=2608188&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: Om Bikram Thapa (omthapa)
Assigned to: Nobody/Anonymous (nobody)
Summary: OpenSIPS latest trunk libmysqlclient segfault 

Initial Comment:
OpenSIPS latest trunk on Debian Lenny/AMD64 dies with libmysqlclient segfault after a MySQL restart. The event that triggers this crash is registration related database query immediately after a MySQL restart. Once OpenSIPS is restarted after a crash, everything runs fine until next MySQL restart.

The log shows:

"opensips[16769]: segfault at 4c8 ip 7f36728bf283 sp 7fff7ba11a90 error 4 in libmysqlclient.so.15.0.0[7f3672862000+1bf000]"
 
and gdb bt gives following results:

---------------
Program terminated with signal 11, Segmentation fault.
[New process 16769]
#0  0x00007f36728bf283 in mysql_stmt_result_metadata ()
   from /usr/lib/libmysqlclient.so.15
(gdb) bt
#0  0x00007f36728bf283 in mysql_stmt_result_metadata ()
   from /usr/lib/libmysqlclient.so.15
#1  0x00007f3672c707b7 in db_mysql_do_prepared_query (conn=0x78b278, 
    query=<value optimized out>, v=0x7fff7ba11d20, n=1, uv=0x0, un=0)
    at dbase.c:363
#2  0x00007f3672c72e1f in db_mysql_query (_h=0x78b278, 
    _k=<value optimized out>, _op=<value optimized out>, _v=0x7fff7ba11d20, 
    _c=<value optimized out>, _n=1, _nc=2, _o=0x0, _r=0x7fff7ba11dc0)
    at dbase.c:591
#3  0x00007f366f3f0398 in authorize (_m=0x78fe98, 
    _realm=<value optimized out>, _table=<value optimized out>, 
    _hftype=<value optimized out>) at authorize.c:107
#4  0x000000000040f869 in do_action (a=0x780a48, msg=0x78fe98) at action.c:961
#5  0x000000000040e7e5 in run_action_list (a=<value optimized out>, 
    msg=0x78fe98) at action.c:139
#6  0x000000000046f194 in eval_elem (e=0x780b18, msg=0x78fe98, val=0x0)
    at route.c:1189
#7  0x00000000004708ed in eval_expr (e=0x120b1e0, msg=0x78fe98, val=0x0)
    at route.c:1486
#8  0x000000000047089c in eval_expr (e=0x780b60, msg=0x78fe98, val=0x0)
    at route.c:1502
#9  0x00000000004708c5 in eval_expr (e=0x780ba8, msg=0x78fe98, val=0x0)
    at route.c:1507
---Type <return> to continue, or q <return> to quit---
#10 0x000000000040f91c in do_action (a=0x780f40, msg=0x78fe98) at action.c:688
#11 0x000000000040e7e5 in run_action_list (a=<value optimized out>, 
    msg=0x78fe98) at action.c:139
#12 0x00000000004114d3 in do_action (a=0x781eb0, msg=0x78fe98) at action.c:705
#13 0x000000000040e7e5 in run_action_list (a=<value optimized out>, 
    msg=0x78fe98) at action.c:139
#14 0x0000000000410e07 in do_action (a=0x77ee88, msg=0x78fe98) at action.c:119
#15 0x000000000040e7e5 in run_action_list (a=<value optimized out>, 
    msg=0x78fe98) at action.c:139
#16 0x00000000004114d3 in do_action (a=0x77f028, msg=0x78fe98) at action.c:705
#17 0x000000000040e7e5 in run_action_list (a=<value optimized out>, 
    msg=0x78fe98) at action.c:139
#18 0x00000000004125fe in run_top_route (a=0x777e78, msg=0x78fe98)
    at action.c:119
#19 0x000000000045e898 in receive_msg (
    buf=0x749180 "REGISTER sip:x.x.x.x SIP/2.0\r\nCSeq: 2 REGISTER\r\nVia: SIP/2.0/UDP x.x.x.x:5061;branch=z9hG4bK60f1b2dd-57fa-dd11-9401-0015c5404858;rport\r\nUser-Agent: Ekiga/2.0.12\r\nAuthorization: Dige"..., 
    len=749, rcv_info=0x7fff7ba13530) at receive.c:165
#20 0x000000000049d3a6 in udp_rcv_loop () at udp_server.c:449
#21 0x00000000004291fb in main (argc=<value optimized out>, 
    argv=0x7fff7ba13718) at main.c:778
----------------


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

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


From anca at opensips.org  Tue Feb 17 12:28:28 2009
From: anca at opensips.org (Anca Vamanu)
Date: Tue, 17 Feb 2009 11:28:28 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[5321] trunk/modules/presence
Message-ID: <E1LZO7o-0004Bd-KH@c3vjzd1.ch3.sourceforge.com>

Revision: 5321
          http://opensips.svn.sourceforge.net/opensips/?rev=5321&view=rev
Author:   anca_vamanu
Date:     2009-02-17 11:28:28 +0000 (Tue, 17 Feb 2009)

Log Message:
-----------
- fixed database reload  query at start up: included fetch support to avoid insufficient memory problems

Modified Paths:
--------------
    trunk/modules/presence/presentity.c
    trunk/modules/presence/subscribe.c


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


From anca at opensips.org  Tue Feb 17 13:13:59 2009
From: anca at opensips.org (Anca Vamanu)
Date: Tue, 17 Feb 2009 12:13:59 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[5322]
	trunk/modules/dialplan/dp_db.c
Message-ID: <E1LZOpr-0006CK-95@3kljzd1.ch3.sourceforge.com>

Revision: 5322
          http://opensips.svn.sourceforge.net/opensips/?rev=5322&view=rev
Author:   anca_vamanu
Date:     2009-02-17 12:13:59 +0000 (Tue, 17 Feb 2009)

Log Message:
-----------
- fixed null check in a debug function - which is called before the ref_lock is initialized

Modified Paths:
--------------
    trunk/modules/dialplan/dp_db.c


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


From anca at opensips.org  Tue Feb 17 13:19:28 2009
From: anca at opensips.org (Anca Vamanu)
Date: Tue, 17 Feb 2009 12:19:28 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[5323]
	trunk/modules/presence/presentity.c
Message-ID: <E1LZOvA-0006Hu-4i@3kljzd1.ch3.sourceforge.com>

Revision: 5323
          http://opensips.svn.sourceforge.net/opensips/?rev=5323&view=rev
Author:   anca_vamanu
Date:     2009-02-17 12:19:27 +0000 (Tue, 17 Feb 2009)

Log Message:
-----------
- fix: took out sql prepare statements when querying for published bodies - causes overflows due to big size

Modified Paths:
--------------
    trunk/modules/presence/presentity.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 Feb 17 13:26:33 2009
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 17 Feb 2009 12:26:33 +0000
Subject: [OpenSIPS-Devel] [ opensips-Bugs-2609050 ] Segmentation fault in
	presence module related to MySQL
Message-ID: <E1LZP21-0003pj-RF@cdv4jf1.ch3.sourceforge.com>

Bugs item #2609050, was opened at 2009-02-17 13:26
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=2609050&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: I?aki Baz (ibc_sf)
Assigned to: Nobody/Anonymous (nobody)
Summary: Segmentation fault in presence module related to MySQL

Initial Comment:
After upgrading to OpenSIPS rev 5320 a server acting as presence server crashes very often.
There is no traffic at all, just 4 users so very log presence traffic.


syslog:
----------
Feb 17 11:41:26 presence_server /usr/sbin/opensips_presence[7205]: DBG:presence:search_event: start event= [dialog]
Feb 17 11:41:26 presence_server /usr/sbin/opensips_presence[7205]: DBG:presence:handle_publish: SIP-If-Match header found
Feb 17 11:41:26 presence_server /usr/sbin/opensips_presence[7205]: DBG:presence:handle_publish: existing etag  = a.1234829890.9781.1.1
Feb 17 11:41:26 presence_server /usr/sbin/opensips_presence[7205]: DBG:presence:handle_publish: Expires header found, value= 8484
Feb 17 11:41:26 presence_server /usr/sbin/opensips_presence[7205]: DBG:db_mysql:db_mysql_do_prepared_query: new query=|select body,sender from presentity where domain=? AND username=? AND
event=? AND etag=?|
Feb 17 11:41:26 presence_server /usr/sbin/opensips_presence[7205]: DBG:db_mysql:db_mysql_do_prepared_query: prepared statement successfully set...
Feb 17 11:41:26 presence_server /usr/sbin/opensips_presence[7205]: DBG:db_mysql:db_mysql_do_prepared_query: set values for the statement run
Feb 17 11:41:26 presence_server /usr/sbin/opensips_presence[7205]: DBG:db_mysql:db_mysql_val2bind: added val (0): len=9; type=254; is_null=0
Feb 17 11:41:26 presence_server /usr/sbin/opensips_presence[7205]: DBG:db_mysql:db_mysql_val2bind: added val (1): len=3; type=254; is_null=0
Feb 17 11:41:26 presence_server /usr/sbin/opensips_presence[7205]: DBG:db_mysql:db_mysql_val2bind: added val (2): len=6; type=254; is_null=0
Feb 17 11:41:26 presence_server /usr/sbin/opensips_presence[7205]: DBG:db_mysql:db_mysql_val2bind: added val (3): len=21; type=254; is_null=0
Feb 17 11:41:26 presence_server /usr/sbin/opensips_presence[7205]: DBG:db_mysql:db_mysql_do_prepared_query: doing BIND_PARAM in...
Feb 17 11:41:26 presence_server /usr/sbin/opensips_presence[7204]: DBG:db_mysql:db_mysql_do_prepared_query: prepared statement successfully set...
Feb 17 11:41:26 presence_server /usr/sbin/opensips_presence[7204]: DBG:db_mysql:db_mysql_do_prepared_query: set values for the statement run
Feb 17 11:41:26 presence_server /usr/sbin/opensips_presence[7204]: DBG:db_mysql:db_mysql_val2bind: added val (0): len=21; type=254; is_null=0
Feb 17 11:41:26 presence_server /usr/sbin/opensips_presence[7204]: DBG:db_mysql:db_mysql_val2bind: added val (1): len=4; type=3; is_null=0
Feb 17 11:41:26 presence_server /usr/sbin/opensips_presence[7204]: DBG:db_mysql:db_mysql_val2bind: added val (2): len=4; type=3; is_null=0
Feb 17 11:41:26 presence_server /usr/sbin/opensips_presence[7204]: DBG:db_mysql:db_mysql_val2bind: added val (3): len=0; type=254; is_null=0
Feb 17 11:41:26 presence_server /usr/sbin/opensips_presence[7204]: DBG:db_mysql:db_mysql_val2bind: added val (4): len=9; type=254; is_null=0
Feb 17 11:41:26 presence_server /usr/sbin/opensips_presence[7204]: DBG:db_mysql:db_mysql_val2bind: added val (5): len=3; type=254; is_null=0
Feb 17 11:41:26 presence_server /usr/sbin/opensips_presence[7204]: DBG:db_mysql:db_mysql_val2bind: added val (6): len=6; type=254; is_null=0
Feb 17 11:41:26 presence_server /usr/sbin/opensips_presence[7204]: DBG:db_mysql:db_mysql_val2bind: added val (7): len=21; type=254; is_null=0
Feb 17 11:41:26 presence_server /usr/sbin/opensips_presence[7204]: DBG:db_mysql:db_mysql_do_prepared_query: doing BIND_PARAM in...
Feb 17 11:41:26 presence_server /usr/sbin/opensips_presence[7222]: CRITICAL:core:receive_fd: EOF on 9
----------------


coredump:
----------------
#0  0x00002ae413496588 in mysql_stmt_prepare () from /usr/lib/libmysqlclient.so.15
#1  0x00002ae4134989dc in cli_stmt_execute () from /usr/lib/libmysqlclient.so.15
#2  0x00002ae413498495 in mysql_stmt_execute () from /usr/lib/libmysqlclient.so.15
#3  0x00002ae41332322c in db_mysql_free_result () from /usr/lib/opensips/modules/db_mysql.so
#4  0x00002ae41332453f in db_mysql_update () from /usr/lib/opensips/modules/db_mysql.so
#5  0x00002ae414a31185 in update_presentity () from /usr/lib/opensips/modules/presence.so
#6  0x00002ae414a342d5 in handle_publish () from /usr/lib/opensips/modules/presence.so
#7  0x000000000040f894 in do_action ()
#8  0x000000000040e0f3 in run_action_list ()
#9  0x0000000000411df5 in do_action ()
#10 0x000000000040e0f3 in run_action_list ()
#11 0x000000000041176f in do_action ()
#12 0x000000000040e0f3 in run_action_list ()
#13 0x0000000000411df5 in do_action ()
#14 0x000000000040e0f3 in run_action_list ()
#15 0x000000000041093a in do_action ()
#16 0x000000000040e0f3 in run_action_list ()
#17 0x000000000041176f in do_action ()
#18 0x000000000040e0f3 in run_action_list ()
#19 0x000000000040e480 in run_top_route ()
#20 0x0000000000441b4c in receive_msg ()
#21 0x0000000000472990 in udp_rcv_loop ()
#22 0x0000000000423917 in main ()
----------------

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

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


From noreply at sourceforge.net  Tue Feb 17 13:40:13 2009
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 17 Feb 2009 12:40:13 +0000
Subject: [OpenSIPS-Devel] [ opensips-Bugs-2608188 ] OpenSIPS latest trunk
	libmysqlclient segfault
Message-ID: <E1LZPFF-0002Os-1Y@d45xhf1.ch3.sourceforge.com>

Bugs item #2608188, was opened at 2009-02-17 08: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=2608188&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: Accepted
>Priority: 8
Private: No
Submitted By: Om Bikram Thapa (omthapa)
>Assigned to: Bogdan-Andrei Iancu (bogdan_iancu)
Summary: OpenSIPS latest trunk libmysqlclient segfault 

Initial Comment:
OpenSIPS latest trunk on Debian Lenny/AMD64 dies with libmysqlclient segfault after a MySQL restart. The event that triggers this crash is registration related database query immediately after a MySQL restart. Once OpenSIPS is restarted after a crash, everything runs fine until next MySQL restart.

The log shows:

"opensips[16769]: segfault at 4c8 ip 7f36728bf283 sp 7fff7ba11a90 error 4 in libmysqlclient.so.15.0.0[7f3672862000+1bf000]"
 
and gdb bt gives following results:

---------------
Program terminated with signal 11, Segmentation fault.
[New process 16769]
#0  0x00007f36728bf283 in mysql_stmt_result_metadata ()
   from /usr/lib/libmysqlclient.so.15
(gdb) bt
#0  0x00007f36728bf283 in mysql_stmt_result_metadata ()
   from /usr/lib/libmysqlclient.so.15
#1  0x00007f3672c707b7 in db_mysql_do_prepared_query (conn=0x78b278, 
    query=<value optimized out>, v=0x7fff7ba11d20, n=1, uv=0x0, un=0)
    at dbase.c:363
#2  0x00007f3672c72e1f in db_mysql_query (_h=0x78b278, 
    _k=<value optimized out>, _op=<value optimized out>, _v=0x7fff7ba11d20, 
    _c=<value optimized out>, _n=1, _nc=2, _o=0x0, _r=0x7fff7ba11dc0)
    at dbase.c:591
#3  0x00007f366f3f0398 in authorize (_m=0x78fe98, 
    _realm=<value optimized out>, _table=<value optimized out>, 
    _hftype=<value optimized out>) at authorize.c:107
#4  0x000000000040f869 in do_action (a=0x780a48, msg=0x78fe98) at action.c:961
#5  0x000000000040e7e5 in run_action_list (a=<value optimized out>, 
    msg=0x78fe98) at action.c:139
#6  0x000000000046f194 in eval_elem (e=0x780b18, msg=0x78fe98, val=0x0)
    at route.c:1189
#7  0x00000000004708ed in eval_expr (e=0x120b1e0, msg=0x78fe98, val=0x0)
    at route.c:1486
#8  0x000000000047089c in eval_expr (e=0x780b60, msg=0x78fe98, val=0x0)
    at route.c:1502
#9  0x00000000004708c5 in eval_expr (e=0x780ba8, msg=0x78fe98, val=0x0)
    at route.c:1507
---Type <return> to continue, or q <return> to quit---
#10 0x000000000040f91c in do_action (a=0x780f40, msg=0x78fe98) at action.c:688
#11 0x000000000040e7e5 in run_action_list (a=<value optimized out>, 
    msg=0x78fe98) at action.c:139
#12 0x00000000004114d3 in do_action (a=0x781eb0, msg=0x78fe98) at action.c:705
#13 0x000000000040e7e5 in run_action_list (a=<value optimized out>, 
    msg=0x78fe98) at action.c:139
#14 0x0000000000410e07 in do_action (a=0x77ee88, msg=0x78fe98) at action.c:119
#15 0x000000000040e7e5 in run_action_list (a=<value optimized out>, 
    msg=0x78fe98) at action.c:139
#16 0x00000000004114d3 in do_action (a=0x77f028, msg=0x78fe98) at action.c:705
#17 0x000000000040e7e5 in run_action_list (a=<value optimized out>, 
    msg=0x78fe98) at action.c:139
#18 0x00000000004125fe in run_top_route (a=0x777e78, msg=0x78fe98)
    at action.c:119
#19 0x000000000045e898 in receive_msg (
    buf=0x749180 "REGISTER sip:x.x.x.x SIP/2.0\r\nCSeq: 2 REGISTER\r\nVia: SIP/2.0/UDP x.x.x.x:5061;branch=z9hG4bK60f1b2dd-57fa-dd11-9401-0015c5404858;rport\r\nUser-Agent: Ekiga/2.0.12\r\nAuthorization: Dige"..., 
    len=749, rcv_info=0x7fff7ba13530) at receive.c:165
#20 0x000000000049d3a6 in udp_rcv_loop () at udp_server.c:449
#21 0x00000000004291fb in main (argc=<value optimized out>, 
    argv=0x7fff7ba13718) at main.c:778
----------------


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

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


From noreply at sourceforge.net  Tue Feb 17 13:47:42 2009
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 17 Feb 2009 12:47:42 +0000
Subject: [OpenSIPS-Devel] [ opensips-Bugs-2584959 ] Error in sending NOTIFY
	for PUBLISH in RLS mode
Message-ID: <E1LZPMU-0004UJ-Fh@g45xhf1.ch3.sourceforge.com>

Bugs item #2584959, was opened at 2009-02-10 14:38
Message generated for change (Comment added) made by bogdan_iancu
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=2584959&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: Duplicate
Priority: 5
Private: No
Submitted By: Nathan (rmnathan)
Assigned to: Nobody/Anonymous (nobody)
Summary: Error in sending NOTIFY for PUBLISH in RLS mode

Initial Comment:
Hi
When opensips got publish for the user(say E1_1) which has in two list subscriptions, it is sending notify to one user only.
For example:
UE2_1 list will have 2 entry uri like E1_1,E1_2
UE2_2 list will have 2 entry uri like E1_2,E1_1

S2_1 subscribe to UE2_1
S2_2 subscribe to UE2_2
If E1_1 send publish, opensips sends notify to S2_1 only. But it should send notify to S2_2 too.

Please find the attached pcap file for detailed call flow.

Regards,
rmnathan


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

>Comment By: Bogdan-Andrei Iancu (bogdan_iancu)
Date: 2009-02-17 14:47

Message:
Same as 2591935

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

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


From bogdan at voice-system.ro  Tue Feb 17 13:53:19 2009
From: bogdan at voice-system.ro (Bogdan-Andrei Iancu)
Date: Tue, 17 Feb 2009 14:53:19 +0200
Subject: [OpenSIPS-Devel] Is it possible to commit new "regex" module
 before	1.5?
In-Reply-To: <200902170041.29072.ibc@aliax.net>
References: <200902170041.29072.ibc@aliax.net>
Message-ID: <499AB33F.2050606@voice-system.ro>

Hi I?aki,

Personally I think we can make an exception, given the circumstances. If 
the new code is tested and does not affect the overall stability of the 
code (which is the most important think here), we can be a bit flexible 
and go for it.

I'm also interested in hearing other people opinion on this.

IMHO the important is the goal and not the rules to get to the goal :D......

Regards,
Bogdan

I?aki Baz Castillo wrote:
> Hi, I planned to commit a new module called "Regex" in SVN trunk but I was 
> away these last days and couldn't submit it before the SVN freeze 
> (yesterday).
>
> I know that no new code should be submitted in this moment, but this module is 
> already tested and working in Kamailio (and of course I've also checked it in 
> OpenSIPS trunk version). For now there are no bugs/issues with it.
>
> Would you, developers, accept this module now or should I wait until 1.5 is 
> released?
>
> Thanks and best regards.
>
>
> PD: Regex module documentation in Kamailio:
>       http://kamailio.org/docs/modules/devel/regex.html
>
>   



From noreply at sourceforge.net  Tue Feb 17 14:00:34 2009
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 17 Feb 2009 13:00:34 +0000
Subject: [OpenSIPS-Devel] [ opensips-Bugs-2609050 ] Segmentation fault in
	presence module related to MySQL
Message-ID: <E1LZPYw-0008Bo-4Z@565xhf1.ch3.sourceforge.com>

Bugs item #2609050, was opened at 2009-02-17 14:26
Message generated for change (Comment added) made by anca_vamanu
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=2609050&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: I?aki Baz (ibc_sf)
Assigned to: Nobody/Anonymous (nobody)
Summary: Segmentation fault in presence module related to MySQL

Initial Comment:
After upgrading to OpenSIPS rev 5320 a server acting as presence server crashes very often.
There is no traffic at all, just 4 users so very log presence traffic.


syslog:
----------
Feb 17 11:41:26 presence_server /usr/sbin/opensips_presence[7205]: DBG:presence:search_event: start event= [dialog]
Feb 17 11:41:26 presence_server /usr/sbin/opensips_presence[7205]: DBG:presence:handle_publish: SIP-If-Match header found
Feb 17 11:41:26 presence_server /usr/sbin/opensips_presence[7205]: DBG:presence:handle_publish: existing etag  = a.1234829890.9781.1.1
Feb 17 11:41:26 presence_server /usr/sbin/opensips_presence[7205]: DBG:presence:handle_publish: Expires header found, value= 8484
Feb 17 11:41:26 presence_server /usr/sbin/opensips_presence[7205]: DBG:db_mysql:db_mysql_do_prepared_query: new query=|select body,sender from presentity where domain=? AND username=? AND
event=? AND etag=?|
Feb 17 11:41:26 presence_server /usr/sbin/opensips_presence[7205]: DBG:db_mysql:db_mysql_do_prepared_query: prepared statement successfully set...
Feb 17 11:41:26 presence_server /usr/sbin/opensips_presence[7205]: DBG:db_mysql:db_mysql_do_prepared_query: set values for the statement run
Feb 17 11:41:26 presence_server /usr/sbin/opensips_presence[7205]: DBG:db_mysql:db_mysql_val2bind: added val (0): len=9; type=254; is_null=0
Feb 17 11:41:26 presence_server /usr/sbin/opensips_presence[7205]: DBG:db_mysql:db_mysql_val2bind: added val (1): len=3; type=254; is_null=0
Feb 17 11:41:26 presence_server /usr/sbin/opensips_presence[7205]: DBG:db_mysql:db_mysql_val2bind: added val (2): len=6; type=254; is_null=0
Feb 17 11:41:26 presence_server /usr/sbin/opensips_presence[7205]: DBG:db_mysql:db_mysql_val2bind: added val (3): len=21; type=254; is_null=0
Feb 17 11:41:26 presence_server /usr/sbin/opensips_presence[7205]: DBG:db_mysql:db_mysql_do_prepared_query: doing BIND_PARAM in...
Feb 17 11:41:26 presence_server /usr/sbin/opensips_presence[7204]: DBG:db_mysql:db_mysql_do_prepared_query: prepared statement successfully set...
Feb 17 11:41:26 presence_server /usr/sbin/opensips_presence[7204]: DBG:db_mysql:db_mysql_do_prepared_query: set values for the statement run
Feb 17 11:41:26 presence_server /usr/sbin/opensips_presence[7204]: DBG:db_mysql:db_mysql_val2bind: added val (0): len=21; type=254; is_null=0
Feb 17 11:41:26 presence_server /usr/sbin/opensips_presence[7204]: DBG:db_mysql:db_mysql_val2bind: added val (1): len=4; type=3; is_null=0
Feb 17 11:41:26 presence_server /usr/sbin/opensips_presence[7204]: DBG:db_mysql:db_mysql_val2bind: added val (2): len=4; type=3; is_null=0
Feb 17 11:41:26 presence_server /usr/sbin/opensips_presence[7204]: DBG:db_mysql:db_mysql_val2bind: added val (3): len=0; type=254; is_null=0
Feb 17 11:41:26 presence_server /usr/sbin/opensips_presence[7204]: DBG:db_mysql:db_mysql_val2bind: added val (4): len=9; type=254; is_null=0
Feb 17 11:41:26 presence_server /usr/sbin/opensips_presence[7204]: DBG:db_mysql:db_mysql_val2bind: added val (5): len=3; type=254; is_null=0
Feb 17 11:41:26 presence_server /usr/sbin/opensips_presence[7204]: DBG:db_mysql:db_mysql_val2bind: added val (6): len=6; type=254; is_null=0
Feb 17 11:41:26 presence_server /usr/sbin/opensips_presence[7204]: DBG:db_mysql:db_mysql_val2bind: added val (7): len=21; type=254; is_null=0
Feb 17 11:41:26 presence_server /usr/sbin/opensips_presence[7204]: DBG:db_mysql:db_mysql_do_prepared_query: doing BIND_PARAM in...
Feb 17 11:41:26 presence_server /usr/sbin/opensips_presence[7222]: CRITICAL:core:receive_fd: EOF on 9
----------------


coredump:
----------------
#0  0x00002ae413496588 in mysql_stmt_prepare () from /usr/lib/libmysqlclient.so.15
#1  0x00002ae4134989dc in cli_stmt_execute () from /usr/lib/libmysqlclient.so.15
#2  0x00002ae413498495 in mysql_stmt_execute () from /usr/lib/libmysqlclient.so.15
#3  0x00002ae41332322c in db_mysql_free_result () from /usr/lib/opensips/modules/db_mysql.so
#4  0x00002ae41332453f in db_mysql_update () from /usr/lib/opensips/modules/db_mysql.so
#5  0x00002ae414a31185 in update_presentity () from /usr/lib/opensips/modules/presence.so
#6  0x00002ae414a342d5 in handle_publish () from /usr/lib/opensips/modules/presence.so
#7  0x000000000040f894 in do_action ()
#8  0x000000000040e0f3 in run_action_list ()
#9  0x0000000000411df5 in do_action ()
#10 0x000000000040e0f3 in run_action_list ()
#11 0x000000000041176f in do_action ()
#12 0x000000000040e0f3 in run_action_list ()
#13 0x0000000000411df5 in do_action ()
#14 0x000000000040e0f3 in run_action_list ()
#15 0x000000000041093a in do_action ()
#16 0x000000000040e0f3 in run_action_list ()
#17 0x000000000041176f in do_action ()
#18 0x000000000040e0f3 in run_action_list ()
#19 0x000000000040e480 in run_top_route ()
#20 0x0000000000441b4c in receive_msg ()
#21 0x0000000000472990 in udp_rcv_loop ()
#22 0x0000000000423917 in main ()
----------------

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

>Comment By: Anca Vamanu (anca_vamanu)
Date: 2009-02-17 15:00

Message:
Hi Inaki,

I also noticed that there are problems with prepare statements and
operations in presentity table. But I thought that they occur only when
querying, because prepare statements put the result in a static buffer.
Just a couple of minutes ago I took out using prepare statements with
queries. 

From noreply at sourceforge.net  Tue Feb 17 15:03:45 2009
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 17 Feb 2009 14:03:45 +0000
Subject: [OpenSIPS-Devel] [ opensips-Bugs-2609050 ] Segmentation fault in
	presence module related to MySQL
Message-ID: <E1LZQY5-0003u1-B4@h45xhf1.ch3.sourceforge.com>

Bugs item #2609050, was opened at 2009-02-17 13:26
Message generated for change (Comment added) made by ibc_sf
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=2609050&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: I?aki Baz (ibc_sf)
Assigned to: Nobody/Anonymous (nobody)
Summary: Segmentation fault in presence module related to MySQL

Initial Comment:
After upgrading to OpenSIPS rev 5320 a server acting as presence server crashes very often.
There is no traffic at all, just 4 users so very log presence traffic.


syslog:
----------
Feb 17 11:41:26 presence_server /usr/sbin/opensips_presence[7205]: DBG:presence:search_event: start event= [dialog]
Feb 17 11:41:26 presence_server /usr/sbin/opensips_presence[7205]: DBG:presence:handle_publish: SIP-If-Match header found
Feb 17 11:41:26 presence_server /usr/sbin/opensips_presence[7205]: DBG:presence:handle_publish: existing etag  = a.1234829890.9781.1.1
Feb 17 11:41:26 presence_server /usr/sbin/opensips_presence[7205]: DBG:presence:handle_publish: Expires header found, value= 8484
Feb 17 11:41:26 presence_server /usr/sbin/opensips_presence[7205]: DBG:db_mysql:db_mysql_do_prepared_query: new query=|select body,sender from presentity where domain=? AND username=? AND
event=? AND etag=?|
Feb 17 11:41:26 presence_server /usr/sbin/opensips_presence[7205]: DBG:db_mysql:db_mysql_do_prepared_query: prepared statement successfully set...
Feb 17 11:41:26 presence_server /usr/sbin/opensips_presence[7205]: DBG:db_mysql:db_mysql_do_prepared_query: set values for the statement run
Feb 17 11:41:26 presence_server /usr/sbin/opensips_presence[7205]: DBG:db_mysql:db_mysql_val2bind: added val (0): len=9; type=254; is_null=0
Feb 17 11:41:26 presence_server /usr/sbin/opensips_presence[7205]: DBG:db_mysql:db_mysql_val2bind: added val (1): len=3; type=254; is_null=0
Feb 17 11:41:26 presence_server /usr/sbin/opensips_presence[7205]: DBG:db_mysql:db_mysql_val2bind: added val (2): len=6; type=254; is_null=0
Feb 17 11:41:26 presence_server /usr/sbin/opensips_presence[7205]: DBG:db_mysql:db_mysql_val2bind: added val (3): len=21; type=254; is_null=0
Feb 17 11:41:26 presence_server /usr/sbin/opensips_presence[7205]: DBG:db_mysql:db_mysql_do_prepared_query: doing BIND_PARAM in...
Feb 17 11:41:26 presence_server /usr/sbin/opensips_presence[7204]: DBG:db_mysql:db_mysql_do_prepared_query: prepared statement successfully set...
Feb 17 11:41:26 presence_server /usr/sbin/opensips_presence[7204]: DBG:db_mysql:db_mysql_do_prepared_query: set values for the statement run
Feb 17 11:41:26 presence_server /usr/sbin/opensips_presence[7204]: DBG:db_mysql:db_mysql_val2bind: added val (0): len=21; type=254; is_null=0
Feb 17 11:41:26 presence_server /usr/sbin/opensips_presence[7204]: DBG:db_mysql:db_mysql_val2bind: added val (1): len=4; type=3; is_null=0
Feb 17 11:41:26 presence_server /usr/sbin/opensips_presence[7204]: DBG:db_mysql:db_mysql_val2bind: added val (2): len=4; type=3; is_null=0
Feb 17 11:41:26 presence_server /usr/sbin/opensips_presence[7204]: DBG:db_mysql:db_mysql_val2bind: added val (3): len=0; type=254; is_null=0
Feb 17 11:41:26 presence_server /usr/sbin/opensips_presence[7204]: DBG:db_mysql:db_mysql_val2bind: added val (4): len=9; type=254; is_null=0
Feb 17 11:41:26 presence_server /usr/sbin/opensips_presence[7204]: DBG:db_mysql:db_mysql_val2bind: added val (5): len=3; type=254; is_null=0
Feb 17 11:41:26 presence_server /usr/sbin/opensips_presence[7204]: DBG:db_mysql:db_mysql_val2bind: added val (6): len=6; type=254; is_null=0
Feb 17 11:41:26 presence_server /usr/sbin/opensips_presence[7204]: DBG:db_mysql:db_mysql_val2bind: added val (7): len=21; type=254; is_null=0
Feb 17 11:41:26 presence_server /usr/sbin/opensips_presence[7204]: DBG:db_mysql:db_mysql_do_prepared_query: doing BIND_PARAM in...
Feb 17 11:41:26 presence_server /usr/sbin/opensips_presence[7222]: CRITICAL:core:receive_fd: EOF on 9
----------------


coredump:
----------------
#0  0x00002ae413496588 in mysql_stmt_prepare () from /usr/lib/libmysqlclient.so.15
#1  0x00002ae4134989dc in cli_stmt_execute () from /usr/lib/libmysqlclient.so.15
#2  0x00002ae413498495 in mysql_stmt_execute () from /usr/lib/libmysqlclient.so.15
#3  0x00002ae41332322c in db_mysql_free_result () from /usr/lib/opensips/modules/db_mysql.so
#4  0x00002ae41332453f in db_mysql_update () from /usr/lib/opensips/modules/db_mysql.so
#5  0x00002ae414a31185 in update_presentity () from /usr/lib/opensips/modules/presence.so
#6  0x00002ae414a342d5 in handle_publish () from /usr/lib/opensips/modules/presence.so
#7  0x000000000040f894 in do_action ()
#8  0x000000000040e0f3 in run_action_list ()
#9  0x0000000000411df5 in do_action ()
#10 0x000000000040e0f3 in run_action_list ()
#11 0x000000000041176f in do_action ()
#12 0x000000000040e0f3 in run_action_list ()
#13 0x0000000000411df5 in do_action ()
#14 0x000000000040e0f3 in run_action_list ()
#15 0x000000000041093a in do_action ()
#16 0x000000000040e0f3 in run_action_list ()
#17 0x000000000041176f in do_action ()
#18 0x000000000040e0f3 in run_action_list ()
#19 0x000000000040e480 in run_top_route ()
#20 0x0000000000441b4c in receive_msg ()
#21 0x0000000000472990 in udp_rcv_loop ()
#22 0x0000000000423917 in main ()
----------------

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

>Comment By: I?aki Baz (ibc_sf)
Date: 2009-02-17 15:03

Message:
Hi Anca, tested again with rev5323 and a similar error occurs with exactly
the same backtrace.

syslog:
------------
/usr/sbin/opensips_presence[19199]: DBG:core:parse_msg: SIP Request:
/usr/sbin/opensips_presence[19199]: DBG:core:parse_msg:  method: 
<SUBSCRIBE>
/usr/sbin/opensips_presence[19199]: DBG:core:parse_msg:  uri:    
<sip:manwe at d
/usr/sbin/opensips_presence[19199]: DBG:core:parse_msg:  version:
<SIP/2.0>
/usr/sbin/opensips_presence[19199]: DBG:core:parse_headers: flags=2
/usr/sbin/opensips_presence[19199]: DBG:core:parse_via_param: found param
type
/usr/sbin/opensips_presence[19199]: DBG:core:parse_via: end of header
reached,
/usr/sbin/opensips_presence[19199]: DBG:core:parse_headers: via found,
flags=2
/usr/sbin/opensips_presence[19199]: DBG:core:parse_headers: this is the
first 
/usr/sbin/opensips_presence[19199]: DBG:core:receive_msg: After
parse_msg...
/usr/sbin/opensips_presence[19199]: DBG:core:receive_msg: preparing to run
rou
/usr/sbin/opensips_presence[19199]: DBG:core:parse_headers: flags=100
/usr/sbin/opensips_presence[19199]: DBG:core:parse_via_param: found param
type
/usr/sbin/opensips_presence[19199]: DBG:core:parse_via_param: found param
type
/usr/sbin/opensips_presence[19199]: DBG:core:parse_via_param: found param
type
/usr/sbin/opensips_presence[19199]: DBG:core:parse_via: end of header
reached,
/usr/sbin/opensips_presence[19199]: DBG:core:parse_headers: via found,
flags=1
/usr/sbin/opensips_presence[19199]: DBG:core:parse_headers: parse_headers:
thi
/usr/sbin/opensips_presence[19199]: DBG:maxfwd:is_maxfwd_present: value =
69
/usr/sbin/opensips_presence[19199]: DBG:core:parse_headers: flags=78
/usr/sbin/opensips_presence[19199]: DBG:core:parse_to: end of header
reached, 
/usr/sbin/opensips_presence[19199]: DBG:core:parse_to: display={},
ruri={sip:m
/usr/sbin/opensips_presence[19199]: DBG:core:get_hdr_field: <To> [23];
uri=[si
/usr/sbin/opensips_presence[19199]: DBG:core:get_hdr_field: to body
[<sip:manw
/usr/sbin/opensips_presence[19199]: DBG:core:get_hdr_field: cseq <CSeq>:
<410>
/usr/sbin/opensips_presence[19199]: DBG:tm:t_lookup_request: start
searching: 
/usr/sbin/opensips_presence[19199]: DBG:tm:matching_3261: RFC3261
transaction 
/usr/sbin/opensips_presence[19199]: DBG:tm:t_lookup_request: no
transaction fo
/usr/sbin/opensips_presence[19199]:
/usr/sbin/opensips_presence[19199]: DBG:uri:has_totag: no totag
/usr/sbin/opensips_presence[19199]: DBG:core:tr_eval_string: i=11 j=8
/usr/sbin/opensips_presence[19199]: DBG:core:parse_headers: flags=8000000
/usr/sbin/opensips_presence[19199]: 14:56:12 - request from
92.122.79.216:3689
/usr/sbin/opensips_presence[19199]: SUBSCRIBE sip:manwe at domain.net
/usr/sbin/opensips_presence[19199]: DBG:core:parse_to_param: tag=doohb
/usr/sbin/opensips_presence[19199]: DBG:core:parse_to: end of header
reached, 
/usr/sbin/opensips_presence[19199]: DBG:core:parse_to: display={"I?aki"},
ruri
/usr/sbin/opensips_presence[19199]: From: "I?aki" <sip:ibc at domain.net>
/usr/sbin/opensips_presence[19199]: DBG:core:pv_get_xto_attr: no Display
name
/usr/sbin/opensips_presence[19199]: To:   <null> <sip:manwe at domain.net>
/usr/sbin/opensips_presence[19199]: DBG:core:parse_headers:
flags=ffffffffffff
/usr/sbin/opensips_presence[19199]: DBG:core:get_hdr_field:
content_length=0
/usr/sbin/opensips_presence[19199]: DBG:core:get_hdr_field: found end of
heade
/usr/sbin/opensips_presence[19199]: DBG:presence:search_event: start
event= [p
/usr/sbin/opensips_presence[19199]: DBG:presence:extract_sdialog_info:
'Expire
/usr/sbin/opensips_presence[19199]: DBG:presence:extract_sdialog_info:
'To' he
/usr/sbin/opensips_presence[19199]: DBG:presence:extract_sdialog_info:
initial
/usr/sbin/opensips_presence[19199]: DBG:presence:extract_sdialog_info:
subs->c
/usr/sbin/opensips_presence[19199]: DBG:core:print_rr_body: current rr is
<sip
/usr/sbin/opensips_presence[19199]: DBG:core:print_rr_body: current rr is
<sip
/usr/sbin/opensips_presence[19199]: DBG:core:print_rr_body: out rr
[<sip:92.12
/usr/sbin/opensips_presence[19199]: DBG:core:print_rr_body: we have 2
records
/usr/sbin/opensips_presence[19199]:
DBG:db_mysql:db_mysql_do_prepared_query: s
/usr/sbin/opensips_presence[19199]: DBG:db_mysql:db_mysql_val2bind: added
val 
/usr/sbin/opensips_presence[19199]: DBG:db_mysql:db_mysql_val2bind: added
val 
/usr/sbin/opensips_presence[19199]: DBG:db_mysql:db_mysql_val2bind: added
val 
/usr/sbin/opensips_presence[19199]: DBG:db_mysql:db_mysql_val2bind: added
val 
/usr/sbin/opensips_presence[19199]:
DBG:db_mysql:db_mysql_do_prepared_query: d
/usr/sbin/opensips_presence[19207]: DBG:core:handle_tcp_child: dead tcp
child 
/usr/sbin/opensips_presence[19207]: DBG:core:io_watch_del: io_watch_del
(0x5fe
/usr/sbin/opensips_presence[19207]: CRITICAL:core:receive_fd: EOF on 21
/usr/sbin/opensips_presence[19207]: DBG:core:handle_ser_child: dead child
11, 
/usr/sbin/opensips_presence[19207]: DBG:core:io_watch_del: io_watch_del
(0x5fe
/usr/sbin/opensips_presence[19188]: INFO:core:handle_sigs: child process
19199
/usr/sbin/opensips_presence[19188]: INFO:core:handle_sigs: core was
generated
/usr/sbin/opensips_presence[19188]: INFO:core:handle_sigs: terminating due
to 
/usr/sbin/opensips_presence[19207]: INFO:core:sig_usr: signal 15 received
------------


Note however that I'm testing presence_dialoginfo module. I will dissable
it now and try again.

PD: There is an ERROR in the logs:

---------
ERROR:db_mysql:db_mysql_do_prepared_query: mysql_stmt_execute() failed:
Lost connection to MySQL server during query
Feb 17 15:02:42 presence_server /usr/sbin/opensips_presence[20031]:
ERROR:presence:update_presentity: inserting new record in database
---------

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

Comment By: Anca Vamanu (anca_vamanu)
Date: 2009-02-17 14:00

Message:
Hi Inaki,

I also noticed that there are problems with prepare statements and
operations in presentity table. But I thought that they occur only when
querying, because prepare statements put the result in a static buffer.
Just a couple of minutes ago I took out using prepare statements with
queries. 

From noreply at sourceforge.net  Tue Feb 17 15:11:07 2009
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 17 Feb 2009 14:11:07 +0000
Subject: [OpenSIPS-Devel] [ opensips-Bugs-2609050 ] Segmentation fault in
	presence module related to MySQL
Message-ID: <E1LZQfD-0002bK-7J@155xhf1.ch3.sourceforge.com>

Bugs item #2609050, was opened at 2009-02-17 14: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=2609050&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: I?aki Baz (ibc_sf)
Assigned to: Nobody/Anonymous (nobody)
Summary: Segmentation fault in presence module related to MySQL

Initial Comment:
After upgrading to OpenSIPS rev 5320 a server acting as presence server crashes very often.
There is no traffic at all, just 4 users so very log presence traffic.


syslog:
----------
Feb 17 11:41:26 presence_server /usr/sbin/opensips_presence[7205]: DBG:presence:search_event: start event= [dialog]
Feb 17 11:41:26 presence_server /usr/sbin/opensips_presence[7205]: DBG:presence:handle_publish: SIP-If-Match header found
Feb 17 11:41:26 presence_server /usr/sbin/opensips_presence[7205]: DBG:presence:handle_publish: existing etag  = a.1234829890.9781.1.1
Feb 17 11:41:26 presence_server /usr/sbin/opensips_presence[7205]: DBG:presence:handle_publish: Expires header found, value= 8484
Feb 17 11:41:26 presence_server /usr/sbin/opensips_presence[7205]: DBG:db_mysql:db_mysql_do_prepared_query: new query=|select body,sender from presentity where domain=? AND username=? AND
event=? AND etag=?|
Feb 17 11:41:26 presence_server /usr/sbin/opensips_presence[7205]: DBG:db_mysql:db_mysql_do_prepared_query: prepared statement successfully set...
Feb 17 11:41:26 presence_server /usr/sbin/opensips_presence[7205]: DBG:db_mysql:db_mysql_do_prepared_query: set values for the statement run
Feb 17 11:41:26 presence_server /usr/sbin/opensips_presence[7205]: DBG:db_mysql:db_mysql_val2bind: added val (0): len=9; type=254; is_null=0
Feb 17 11:41:26 presence_server /usr/sbin/opensips_presence[7205]: DBG:db_mysql:db_mysql_val2bind: added val (1): len=3; type=254; is_null=0
Feb 17 11:41:26 presence_server /usr/sbin/opensips_presence[7205]: DBG:db_mysql:db_mysql_val2bind: added val (2): len=6; type=254; is_null=0
Feb 17 11:41:26 presence_server /usr/sbin/opensips_presence[7205]: DBG:db_mysql:db_mysql_val2bind: added val (3): len=21; type=254; is_null=0
Feb 17 11:41:26 presence_server /usr/sbin/opensips_presence[7205]: DBG:db_mysql:db_mysql_do_prepared_query: doing BIND_PARAM in...
Feb 17 11:41:26 presence_server /usr/sbin/opensips_presence[7204]: DBG:db_mysql:db_mysql_do_prepared_query: prepared statement successfully set...
Feb 17 11:41:26 presence_server /usr/sbin/opensips_presence[7204]: DBG:db_mysql:db_mysql_do_prepared_query: set values for the statement run
Feb 17 11:41:26 presence_server /usr/sbin/opensips_presence[7204]: DBG:db_mysql:db_mysql_val2bind: added val (0): len=21; type=254; is_null=0
Feb 17 11:41:26 presence_server /usr/sbin/opensips_presence[7204]: DBG:db_mysql:db_mysql_val2bind: added val (1): len=4; type=3; is_null=0
Feb 17 11:41:26 presence_server /usr/sbin/opensips_presence[7204]: DBG:db_mysql:db_mysql_val2bind: added val (2): len=4; type=3; is_null=0
Feb 17 11:41:26 presence_server /usr/sbin/opensips_presence[7204]: DBG:db_mysql:db_mysql_val2bind: added val (3): len=0; type=254; is_null=0
Feb 17 11:41:26 presence_server /usr/sbin/opensips_presence[7204]: DBG:db_mysql:db_mysql_val2bind: added val (4): len=9; type=254; is_null=0
Feb 17 11:41:26 presence_server /usr/sbin/opensips_presence[7204]: DBG:db_mysql:db_mysql_val2bind: added val (5): len=3; type=254; is_null=0
Feb 17 11:41:26 presence_server /usr/sbin/opensips_presence[7204]: DBG:db_mysql:db_mysql_val2bind: added val (6): len=6; type=254; is_null=0
Feb 17 11:41:26 presence_server /usr/sbin/opensips_presence[7204]: DBG:db_mysql:db_mysql_val2bind: added val (7): len=21; type=254; is_null=0
Feb 17 11:41:26 presence_server /usr/sbin/opensips_presence[7204]: DBG:db_mysql:db_mysql_do_prepared_query: doing BIND_PARAM in...
Feb 17 11:41:26 presence_server /usr/sbin/opensips_presence[7222]: CRITICAL:core:receive_fd: EOF on 9
----------------


coredump:
----------------
#0  0x00002ae413496588 in mysql_stmt_prepare () from /usr/lib/libmysqlclient.so.15
#1  0x00002ae4134989dc in cli_stmt_execute () from /usr/lib/libmysqlclient.so.15
#2  0x00002ae413498495 in mysql_stmt_execute () from /usr/lib/libmysqlclient.so.15
#3  0x00002ae41332322c in db_mysql_free_result () from /usr/lib/opensips/modules/db_mysql.so
#4  0x00002ae41332453f in db_mysql_update () from /usr/lib/opensips/modules/db_mysql.so
#5  0x00002ae414a31185 in update_presentity () from /usr/lib/opensips/modules/presence.so
#6  0x00002ae414a342d5 in handle_publish () from /usr/lib/opensips/modules/presence.so
#7  0x000000000040f894 in do_action ()
#8  0x000000000040e0f3 in run_action_list ()
#9  0x0000000000411df5 in do_action ()
#10 0x000000000040e0f3 in run_action_list ()
#11 0x000000000041176f in do_action ()
#12 0x000000000040e0f3 in run_action_list ()
#13 0x0000000000411df5 in do_action ()
#14 0x000000000040e0f3 in run_action_list ()
#15 0x000000000041093a in do_action ()
#16 0x000000000040e0f3 in run_action_list ()
#17 0x000000000041176f in do_action ()
#18 0x000000000040e0f3 in run_action_list ()
#19 0x000000000040e480 in run_top_route ()
#20 0x0000000000441b4c in receive_msg ()
#21 0x0000000000472990 in udp_rcv_loop ()
#22 0x0000000000423917 in main ()
----------------

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

>Comment By: Bogdan-Andrei Iancu (bogdan_iancu)
Date: 2009-02-17 16:11

Message:
Hi,

maybe this is related to bug #2608188 - it a report for prepared
statements crashing when reconnecting to mysql server....maybe it is the
same case here...

Regards,
Bogdan

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

Comment By: I?aki Baz (ibc_sf)
Date: 2009-02-17 16:03

Message:
Hi Anca, tested again with rev5323 and a similar error occurs with exactly
the same backtrace.

syslog:
------------
/usr/sbin/opensips_presence[19199]: DBG:core:parse_msg: SIP Request:
/usr/sbin/opensips_presence[19199]: DBG:core:parse_msg:  method: 
<SUBSCRIBE>
/usr/sbin/opensips_presence[19199]: DBG:core:parse_msg:  uri:    
<sip:manwe at d
/usr/sbin/opensips_presence[19199]: DBG:core:parse_msg:  version:
<SIP/2.0>
/usr/sbin/opensips_presence[19199]: DBG:core:parse_headers: flags=2
/usr/sbin/opensips_presence[19199]: DBG:core:parse_via_param: found param
type
/usr/sbin/opensips_presence[19199]: DBG:core:parse_via: end of header
reached,
/usr/sbin/opensips_presence[19199]: DBG:core:parse_headers: via found,
flags=2
/usr/sbin/opensips_presence[19199]: DBG:core:parse_headers: this is the
first 
/usr/sbin/opensips_presence[19199]: DBG:core:receive_msg: After
parse_msg...
/usr/sbin/opensips_presence[19199]: DBG:core:receive_msg: preparing to run
rou
/usr/sbin/opensips_presence[19199]: DBG:core:parse_headers: flags=100
/usr/sbin/opensips_presence[19199]: DBG:core:parse_via_param: found param
type
/usr/sbin/opensips_presence[19199]: DBG:core:parse_via_param: found param
type
/usr/sbin/opensips_presence[19199]: DBG:core:parse_via_param: found param
type
/usr/sbin/opensips_presence[19199]: DBG:core:parse_via: end of header
reached,
/usr/sbin/opensips_presence[19199]: DBG:core:parse_headers: via found,
flags=1
/usr/sbin/opensips_presence[19199]: DBG:core:parse_headers: parse_headers:
thi
/usr/sbin/opensips_presence[19199]: DBG:maxfwd:is_maxfwd_present: value =
69
/usr/sbin/opensips_presence[19199]: DBG:core:parse_headers: flags=78
/usr/sbin/opensips_presence[19199]: DBG:core:parse_to: end of header
reached, 
/usr/sbin/opensips_presence[19199]: DBG:core:parse_to: display={},
ruri={sip:m
/usr/sbin/opensips_presence[19199]: DBG:core:get_hdr_field: <To> [23];
uri=[si
/usr/sbin/opensips_presence[19199]: DBG:core:get_hdr_field: to body
[<sip:manw
/usr/sbin/opensips_presence[19199]: DBG:core:get_hdr_field: cseq <CSeq>:
<410>
/usr/sbin/opensips_presence[19199]: DBG:tm:t_lookup_request: start
searching: 
/usr/sbin/opensips_presence[19199]: DBG:tm:matching_3261: RFC3261
transaction 
/usr/sbin/opensips_presence[19199]: DBG:tm:t_lookup_request: no
transaction fo
/usr/sbin/opensips_presence[19199]:
/usr/sbin/opensips_presence[19199]: DBG:uri:has_totag: no totag
/usr/sbin/opensips_presence[19199]: DBG:core:tr_eval_string: i=11 j=8
/usr/sbin/opensips_presence[19199]: DBG:core:parse_headers: flags=8000000
/usr/sbin/opensips_presence[19199]: 14:56:12 - request from
92.122.79.216:3689
/usr/sbin/opensips_presence[19199]: SUBSCRIBE sip:manwe at domain.net
/usr/sbin/opensips_presence[19199]: DBG:core:parse_to_param: tag=doohb
/usr/sbin/opensips_presence[19199]: DBG:core:parse_to: end of header
reached, 
/usr/sbin/opensips_presence[19199]: DBG:core:parse_to: display={"I?aki"},
ruri
/usr/sbin/opensips_presence[19199]: From: "I?aki" <sip:ibc at domain.net>
/usr/sbin/opensips_presence[19199]: DBG:core:pv_get_xto_attr: no Display
name
/usr/sbin/opensips_presence[19199]: To:   <null> <sip:manwe at domain.net>
/usr/sbin/opensips_presence[19199]: DBG:core:parse_headers:
flags=ffffffffffff
/usr/sbin/opensips_presence[19199]: DBG:core:get_hdr_field:
content_length=0
/usr/sbin/opensips_presence[19199]: DBG:core:get_hdr_field: found end of
heade
/usr/sbin/opensips_presence[19199]: DBG:presence:search_event: start
event= [p
/usr/sbin/opensips_presence[19199]: DBG:presence:extract_sdialog_info:
'Expire
/usr/sbin/opensips_presence[19199]: DBG:presence:extract_sdialog_info:
'To' he
/usr/sbin/opensips_presence[19199]: DBG:presence:extract_sdialog_info:
initial
/usr/sbin/opensips_presence[19199]: DBG:presence:extract_sdialog_info:
subs->c
/usr/sbin/opensips_presence[19199]: DBG:core:print_rr_body: current rr is
<sip
/usr/sbin/opensips_presence[19199]: DBG:core:print_rr_body: current rr is
<sip
/usr/sbin/opensips_presence[19199]: DBG:core:print_rr_body: out rr
[<sip:92.12
/usr/sbin/opensips_presence[19199]: DBG:core:print_rr_body: we have 2
records
/usr/sbin/opensips_presence[19199]:
DBG:db_mysql:db_mysql_do_prepared_query: s
/usr/sbin/opensips_presence[19199]: DBG:db_mysql:db_mysql_val2bind: added
val 
/usr/sbin/opensips_presence[19199]: DBG:db_mysql:db_mysql_val2bind: added
val 
/usr/sbin/opensips_presence[19199]: DBG:db_mysql:db_mysql_val2bind: added
val 
/usr/sbin/opensips_presence[19199]: DBG:db_mysql:db_mysql_val2bind: added
val 
/usr/sbin/opensips_presence[19199]:
DBG:db_mysql:db_mysql_do_prepared_query: d
/usr/sbin/opensips_presence[19207]: DBG:core:handle_tcp_child: dead tcp
child 
/usr/sbin/opensips_presence[19207]: DBG:core:io_watch_del: io_watch_del
(0x5fe
/usr/sbin/opensips_presence[19207]: CRITICAL:core:receive_fd: EOF on 21
/usr/sbin/opensips_presence[19207]: DBG:core:handle_ser_child: dead child
11, 
/usr/sbin/opensips_presence[19207]: DBG:core:io_watch_del: io_watch_del
(0x5fe
/usr/sbin/opensips_presence[19188]: INFO:core:handle_sigs: child process
19199
/usr/sbin/opensips_presence[19188]: INFO:core:handle_sigs: core was
generated
/usr/sbin/opensips_presence[19188]: INFO:core:handle_sigs: terminating due
to 
/usr/sbin/opensips_presence[19207]: INFO:core:sig_usr: signal 15 received
------------


Note however that I'm testing presence_dialoginfo module. I will dissable
it now and try again.

PD: There is an ERROR in the logs:

---------
ERROR:db_mysql:db_mysql_do_prepared_query: mysql_stmt_execute() failed:
Lost connection to MySQL server during query
Feb 17 15:02:42 presence_server /usr/sbin/opensips_presence[20031]:
ERROR:presence:update_presentity: inserting new record in database
---------

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

Comment By: Anca Vamanu (anca_vamanu)
Date: 2009-02-17 15:00

Message:
Hi Inaki,

I also noticed that there are problems with prepare statements and
operations in presentity table. But I thought that they occur only when
querying, because prepare statements put the result in a static buffer.
Just a couple of minutes ago I took out using prepare statements with
queries. 

From bogdan at voice-system.ro  Tue Feb 17 15:27:45 2009
From: bogdan at voice-system.ro (Bogdan-Andrei Iancu)
Date: Tue, 17 Feb 2009 14:27:45 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[5324]
	trunk/scripts/opensipsdbctl.mysql
Message-ID: <E1LZQvJ-0006IQ-CO@bj8yhf1.ch3.sourceforge.com>

Revision: 5324
          http://opensips.svn.sourceforge.net/opensips/?rev=5324&view=rev
Author:   bogdan_iancu
Date:     2009-02-17 14:27:45 +0000 (Tue, 17 Feb 2009)

Log Message:
-----------
At charset_test() in opensipsdbctl.mysql script. grep is called with an
option which is not supported by standard grep in Solaris.
This patch proposes a different approach for that case; it defines a
variable which counts how many times user has failed in passing a supported
charset; after 3 tries, script exits with error code of 1.

Closes 2577793.
Credits go to Sergio Gutierrez.

Modified Paths:
--------------
    trunk/scripts/opensipsdbctl.mysql


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


From bogdan at voice-system.ro  Tue Feb 17 15:29:29 2009
From: bogdan at voice-system.ro (Bogdan-Andrei Iancu)
Date: Tue, 17 Feb 2009 14:29:29 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[5325]
	branches/1.4/scripts/opensipsdbctl.mysql
Message-ID: <E1LZQwz-0006LW-HM@bj8yhf1.ch3.sourceforge.com>

Revision: 5325
          http://opensips.svn.sourceforge.net/opensips/?rev=5325&view=rev
Author:   bogdan_iancu
Date:     2009-02-17 14:29:29 +0000 (Tue, 17 Feb 2009)

Log Message:
-----------
Backport from trunk (rev #5324)

At charset_test() in opensipsdbctl.mysql script. grep is called with an
option which is not supported by standard grep in Solaris.
This patch proposes a different approach for that case; it defines a
variable which counts how many times user has failed in passing a supported
charset; after 3 tries, script exits with error code of 1.

Closes 2577793.
Credits go to Sergio Gutierrez.

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

Modified Paths:
--------------
    branches/1.4/scripts/opensipsdbctl.mysql


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


From noreply at sourceforge.net  Tue Feb 17 15:30:09 2009
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 17 Feb 2009 14:30:09 +0000
Subject: [OpenSIPS-Devel] [ opensips-Patches-2577793 ] Avoid usage of
	unsupported grep option in db script
Message-ID: <E1LZQxd-0002xO-3N@d55xhf1.ch3.sourceforge.com>

Patches item #2577793, was opened at 2009-02-07 18:51
Message generated for change (Comment added) made by bogdan_iancu
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086412&aid=2577793&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: Closed
>Resolution: Fixed
Priority: 5
Private: No
Submitted By: Sergio Gutierrez (saguti)
>Assigned to: Bogdan-Andrei Iancu (bogdan_iancu)
Summary: Avoid usage of unsupported grep option in db script

Initial Comment:
At charset_test() in opensipsdbctl.mysql script. grep is called with an option which is not supported by standard grep in Solaris.
This patch proposes a different approach for that case; it defines a variable which counts how many times user has failed in passing a supported charset; after 3 tries, script exits with error code of 1.

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

>Comment By: Bogdan-Andrei Iancu (bogdan_iancu)
Date: 2009-02-17 16:30

Message:
Hi Sergio,

Thanks for the fix - I applied it on the 1.5 and 1.4 versions.

Thanks and regards,
Bogdan

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

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


From bogdan at voice-system.ro  Tue Feb 17 15:49:48 2009
From: bogdan at voice-system.ro (Bogdan-Andrei Iancu)
Date: Tue, 17 Feb 2009 14:49:48 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[5326] trunk/Makefile.defs
Message-ID: <E1LZRGe-0004gu-DZ@d5vjzd1.ch3.sourceforge.com>

Revision: 5326
          http://opensips.svn.sourceforge.net/opensips/?rev=5326&view=rev
Author:   bogdan_iancu
Date:     2009-02-17 14:49:48 +0000 (Tue, 17 Feb 2009)

Log Message:
-----------
This patch defines an approach to detect SPARC processors, so that more
specific optimization options can be added to GCC.
The family of chips detected are UltraSPARC II, UltraSPARC III (Cu and i),
and UltraSPARC T1; for this last one, optimizations are used only if gcc is
> 4.2.
See http://gcc.gnu.org/onlinedocs/gcc/SPARC-Options.html#SPARC-Options for
more info.

Closes patch 2512634.
Credits go to Sergio Gutierrez

Modified Paths:
--------------
    trunk/Makefile.defs


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


From saguti at gmail.com  Tue Feb 17 15:50:31 2009
From: saguti at gmail.com (Sergio Gutierrez)
Date: Tue, 17 Feb 2009 09:50:31 -0500
Subject: [OpenSIPS-Devel] Is it possible to commit new "regex" module
	before 1.5?
In-Reply-To: <499AB33F.2050606@voice-system.ro>
References: <200902170041.29072.ibc@aliax.net>
	<499AB33F.2050606@voice-system.ro>
Message-ID: <8a4af3e20902170650m1a172f8eq512e926f8362e314@mail.gmail.com>

Hi all.

I agree with Bogdan. According module documentation, it offers a very useful
functionality, which would be nice to include it in 1.5.0.

Regards.

Sergio.

On Tue, Feb 17, 2009 at 7:53 AM, Bogdan-Andrei Iancu <bogdan at voice-system.ro
> wrote:

> Hi I?aki,
>
> Personally I think we can make an exception, given the circumstances. If
> the new code is tested and does not affect the overall stability of the
> code (which is the most important think here), we can be a bit flexible
> and go for it.
>
> I'm also interested in hearing other people opinion on this.
>
> IMHO the important is the goal and not the rules to get to the goal
> :D......
>
> Regards,
> Bogdan
>
> I?aki Baz Castillo wrote:
> > Hi, I planned to commit a new module called "Regex" in SVN trunk but I
> was
> > away these last days and couldn't submit it before the SVN freeze
> > (yesterday).
> >
> > I know that no new code should be submitted in this moment, but this
> module is
> > already tested and working in Kamailio (and of course I've also checked
> it in
> > OpenSIPS trunk version). For now there are no bugs/issues with it.
> >
> > Would you, developers, accept this module now or should I wait until 1.5
> is
> > released?
> >
> > Thanks and best regards.
> >
> >
> > PD: Regex module documentation in Kamailio:
> >       http://kamailio.org/docs/modules/devel/regex.html
> >
> >
>
>
> _______________________________________________
> Devel mailing list
> Devel at lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
>



-- 
Sergio Guti?rrez
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.opensips.org/pipermail/devel/attachments/20090217/398aaca7/attachment.htm 

From noreply at sourceforge.net  Tue Feb 17 15:52:08 2009
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 17 Feb 2009 14:52:08 +0000
Subject: [OpenSIPS-Devel] [ opensips-Patches-2512634 ] Detection of SPARC
	processors to use specific optimizations
Message-ID: <E1LZRIu-0004zr-Re@h45xhf1.ch3.sourceforge.com>

Patches item #2512634, was opened at 2009-01-16 09:22
Message generated for change (Comment added) made by bogdan_iancu
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086412&aid=2512634&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: trunk
>Status: Closed
>Resolution: Accepted
Priority: 5
Private: No
Submitted By: Sergio Gutierrez (saguti)
Assigned to: Bogdan-Andrei Iancu (bogdan_iancu)
Summary: Detection of SPARC processors to use specific optimizations

Initial Comment:
This patch defines an approach to detect SPARC processors, so that more specific optimization options can be added to GCC.
The family of chips detected are UltraSPARC II, UltraSPARC III (Cu and i), and UltraSPARC T1; for this last one, optimizations are used only if gcc is > 4.2.
See http://gcc.gnu.org/onlinedocs/gcc/SPARC-Options.html#SPARC-Options for more info.

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

>Comment By: Bogdan-Andrei Iancu (bogdan_iancu)
Date: 2009-02-17 16:52

Message:
Hi Sergio,

I applied your patch on 1.5 and 1.4 version.

Thanks and regards,
Bogdan

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

Comment By: Bogdan-Andrei Iancu (bogdan_iancu)
Date: 2009-01-22 13:07

Message:
OK - I will overview this asap

Regards,
Bogdan

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

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


From bogdan at voice-system.ro  Tue Feb 17 15:52:20 2009
From: bogdan at voice-system.ro (Bogdan-Andrei Iancu)
Date: Tue, 17 Feb 2009 14:52:20 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[5327]
	branches/1.4/Makefile.defs
Message-ID: <E1LZRJ6-0004jw-0a@d5vjzd1.ch3.sourceforge.com>

Revision: 5327
          http://opensips.svn.sourceforge.net/opensips/?rev=5327&view=rev
Author:   bogdan_iancu
Date:     2009-02-17 14:52:19 +0000 (Tue, 17 Feb 2009)

Log Message:
-----------
Backport from trunk (rev #5326)

This patch defines an approach to detect SPARC processors, so that more
specific optimization options can be added to GCC.
The family of chips detected are UltraSPARC II, UltraSPARC III (Cu and i),
and UltraSPARC T1; for this last one, optimizations are used only if gcc is
> 4.2.
See http://gcc.gnu.org/onlinedocs/gcc/SPARC-Options.html#SPARC-Options for
more info.

Closes patch 2512634.
Credits go to Sergio Gutierrez

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

Modified Paths:
--------------
    branches/1.4/Makefile.defs


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


From noreply at sourceforge.net  Tue Feb 17 16:07:42 2009
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 17 Feb 2009 15:07:42 +0000
Subject: [OpenSIPS-Devel] [ opensips-Patches-2264067 ] Ambiguous return and
	possible memory leak
Message-ID: <E1LZRXy-0005MQ-7h@h45xhf1.ch3.sourceforge.com>

Patches item #2264067, was opened at 2008-11-11 21:02
Message generated for change (Comment added) made by bogdan_iancu
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086412&aid=2264067&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: Invalid
Priority: 5
Private: No
Submitted By: Sergio Gutierrez (saguti)
Assigned to: Bogdan-Andrei Iancu (bogdan_iancu)
Summary: Ambiguous return and possible memory leak

Initial Comment:
There is an ambiguity in return value within exec module, and a possible memory leak for not adequate memory free.

The patch fixes both.

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

>Comment By: Bogdan-Andrei Iancu (bogdan_iancu)
Date: 2009-02-17 17:07

Message:
proved to be invalid.

Thanks and regards,
Bogdan

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

Comment By: Bogdan-Andrei Iancu (bogdan_iancu)
Date: 2008-11-13 11:07

Message:
Hi Sergio,

> line 136, at exec_str: If pipe cannot be opened, goes to error01, memory
is freed, but return is missed.

There is a return there - the one from error00; the code is set (default)
ret=-1 at the beginning - this is ok here.

> line 160, at exec_str: If there is error reading uri (fgets within
while),goes to error02, which only has return ret;

Yes, and ret is preset to -1; also mem is freed in error01

> line 165, at exec_str: If there is error appending branch, goes to
error02, which only has return ret;

Same as above

> line 172, at exec_str: If message has no from uri, goes to error02,
which onlye has return ret;

Same as above.

Regards,
Bogdan

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

Comment By: Sergio Gutierrez (saguti)
Date: 2008-11-12 19:32

Message:
Hi Bogdan.

As I see:

line 112, at exec_str: Memory is allocated.
line 136, at exec_str: If pipe cannot be opened, goes to error01, memory
is freed, but return is missed.
line 160, at exec_str: If there is error reading uri (fgets within while),
goes to error02, which only has return ret;
line 165, at exec_str: If there is error appending branch, goes to
error02, which only has return ret;
line 172, at exec_str: If message has no from uri, goes to error02, which
onlye has return ret;

Block defined by error02 does not have memory freeing. Does the program
continue through error01 and error00?

Regards.

Sergio.


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

Comment By: Bogdan-Andrei Iancu (bogdan_iancu)
Date: 2008-11-12 19:21

Message:
Hi Sergio,

I do not see the leak - the original code looks safe to me - if there is a
case where you spoted a possible leak, please describe the case (the flow
in the function).

Thanks and regards,
Bogdan

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

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


From noreply at sourceforge.net  Tue Feb 17 17:35:30 2009
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 17 Feb 2009 16:35:30 +0000
Subject: [OpenSIPS-Devel] [ opensips-Bugs-2609529 ] Segmentation fault
	related to 'pua' module
Message-ID: <E1LZSuw-0003mH-Kx@565xhf1.ch3.sourceforge.com>

Bugs item #2609529, was opened at 2009-02-17 17:35
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=2609529&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: I?aki Baz (ibc_sf)
Assigned to: Nobody/Anonymous (nobody)
Summary: Segmentation fault related to 'pua' module

Initial Comment:
OpenSIPS rev 5323.

This OpenSIPS acts as a proxy for presence messages which are routed to an OpenSIPS presence server running in a different port.


syslog:
---------------
/usr/sbin/opensips[20978]: DBG:core:parse_msg:  version: <SIP/2.
/usr/sbin/opensips[20978]: DBG:core:parse_msg:  status:  <489>
/usr/sbin/opensips[20978]: DBG:core:parse_msg:  reason:  <Bad Ev
/usr/sbin/opensips[20978]: DBG:core:parse_headers: flags=2
/usr/sbin/opensips[20978]: DBG:core:parse_via_param: found param
/usr/sbin/opensips[20978]: DBG:core:parse_via: end of header rea
/usr/sbin/opensips[20978]: DBG:core:parse_headers: via found, fl
/usr/sbin/opensips[20978]: DBG:core:parse_headers: this is the f
/usr/sbin/opensips[20978]: DBG:core:receive_msg: After parse_msg
/usr/sbin/opensips[20978]: DBG:core:forward_reply: found module 
/usr/sbin/opensips[20978]: DBG:core:parse_headers: flags=4
/usr/sbin/opensips[20978]: DBG:core:parse_via_param: found param
/usr/sbin/opensips[20978]: DBG:core:parse_via_param: found param
/usr/sbin/opensips[20978]: DBG:core:parse_via_param: found param
/usr/sbin/opensips[20978]: DBG:core:parse_via: end of header rea
/usr/sbin/opensips[20978]: DBG:core:parse_headers: via found, fl
/usr/sbin/opensips[20978]: DBG:core:parse_headers: parse_headers
/usr/sbin/opensips[20978]: DBG:core:forward_reply: found module 
/usr/sbin/opensips[20978]: DBG:tm:t_check: start=0xfffffffffffff
/usr/sbin/opensips[20978]: DBG:core:parse_headers: flags=22
/usr/sbin/opensips[20978]: DBG:core:parse_to_param: tag=82e3ea5b
/usr/sbin/opensips[20978]: DBG:core:parse_to: end of header reac
/usr/sbin/opensips[20978]: DBG:core:parse_to: display={}, ruri={
/usr/sbin/opensips[20978]: DBG:core:get_hdr_field: <To> [63]; ur
/usr/sbin/opensips[20978]: DBG:core:get_hdr_field: to body [<sip
/usr/sbin/opensips[20978]: DBG:core:get_hdr_field: cseq <CSeq>: 
/usr/sbin/opensips[20978]: DBG:tm:t_reply_matching: hash 65085 l
/usr/sbin/opensips[20978]: DBG:tm:t_reply_matching: REF_UNSAFE: 
/usr/sbin/opensips[20978]: DBG:tm:t_reply_matching: reply matche
/usr/sbin/opensips[20978]: DBG:tm:run_trans_callbacks: trans=0x2
/usr/sbin/opensips[20978]: DBG:tm:t_check: end=0x2b936cb4ff10
/usr/sbin/opensips[20978]: DBG:tm:reply_received: org. status ua
/usr/sbin/opensips[20978]:  ## onreply_route[ON_REPLY_DEFAULT]
/usr/sbin/opensips[20978]: DBG:core:tr_eval_string: i=11 j=8
/usr/sbin/opensips[20978]: DBG:core:parse_headers: flags=8000000
/usr/sbin/opensips[20978]: DBG:core:get_hdr_field: content_lengt
/usr/sbin/opensips[20978]: DBG:core:get_hdr_field: found end of 
/usr/sbin/opensips[20978]: DBG:core:pv_get_useragent: no User-Ag
/usr/sbin/opensips[20978]: 15:43:27 - Reply from 99.131.79.216:5
/usr/sbin/opensips[20978]: 489 (SUBSCRIBE): Bad Event
/usr/sbin/opensips[20978]: DBG:tm:t_should_relay_response: T_cod
/usr/sbin/opensips[20978]: DBG:tm:t_pick_branch: picked branch 0
/usr/sbin/opensips[20978]: DBG:tm:is_3263_failure: dns-failover 
/usr/sbin/opensips[20978]: DBG:tm:relay_reply: branch=0, save=0,
/usr/sbin/opensips[20978]: DBG:core:build_res_buf_from_sip_res: 
/usr/sbin/opensips[20978]: DBG:core:build_res_buf_from_sip_res: 
/usr/sbin/opensips[20978]: DBG:core:_shm_resize: resize(0) calle
/usr/sbin/opensips[20978]: DBG:tm:insert_timer_unsafe: [2]: 0x2b
/usr/sbin/opensips[20978]: DBG:tm:relay_reply: sent buf=0x6b7920
/usr/sbin/opensips[20978]: DBG:tm:cleanup_uac_timers: RETR/FR ti
/usr/sbin/opensips[20978]: DBG:tm:t_unref: UNREF_UNSAFE: after i
/usr/sbin/opensips[20978]: DBG:core:destroy_avp_list: destroying
/usr/sbin/opensips[20978]: DBG:core:receive_msg: cleaning up
/usr/sbin/opensips[20934]: DBG:core:tcp_send: buf= SUBSCRIBE sip
/usr/sbin/opensips[20934]: DBG:tm:set_timer: relative timeout is
/usr/sbin/opensips[20934]: DBG:tm:insert_timer_unsafe: [0]: 0x2b
/usr/sbin/opensips[20934]: DBG:tm:t_relay_to: new transaction fw
/usr/sbin/opensips[20934]: DBG:tm:t_unref: UNREF_UNSAFE: after i
/usr/sbin/opensips[20934]: DBG:core:destroy_avp_list: destroying
/usr/sbin/opensips[20934]: DBG:core:receive_msg: cleaning up
/usr/sbin/opensips[20994]: CRITICAL:core:receive_fd: EOF on 46
---------------



coredump:
---------------
Core was generated by `/usr/sbin/opensips -P /var/run/opensips/opensips.pid -m 128 -u opensips -g open'.
Program terminated with signal 11, Segmentation fault.
#0  0x00002b936a901d78 in publ_build_hdr () from /usr/lib/opensips/modules/pua.so
(gdb) bt
#0  0x00002b936a901d78 in publ_build_hdr () from /usr/lib/opensips/modules/pua.so
#1  0x00002b936a8fee4c in bind_pua () from /usr/lib/opensips/modules/pua.so
#2  0x000000000046960c in start_timer_processes ()
#3  0x0000000000423661 in main ()
---------------

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

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


From noreply at sourceforge.net  Tue Feb 17 17:38:26 2009
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 17 Feb 2009 16:38:26 +0000
Subject: [OpenSIPS-Devel] [ opensips-Bugs-2335003 ]
	ERROR:db_mysql:db_mysql_submit_query
Message-ID: <E1LZSxm-0005LI-AB@155xhf1.ch3.sourceforge.com>

Bugs item #2335003, was opened at 2008-11-23 22:54
Message generated for change (Comment added) made by ibc_sf
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=2335003&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: 1
Private: No
Submitted By: I?aki Baz (ibc_sf)
Assigned to: Nobody/Anonymous (nobody)
Summary: ERROR:db_mysql:db_mysql_submit_query

Initial Comment:
This error occurs to me very often (sometimes during an INVITE, during a SUBSCRIBE...). If it occurs during an INVITE, then OpenSIPS returns 500:

-----------
Nov 23 16:42:07 [12195] ERROR:db_mysql:db_mysql_submit_query: driver error on 
query: Commands out of sync; you can't run this command now
Nov 23 16:42:07 [12195] ERROR:core:db_do_query: error while submitting query
Nov 23 16:42:07 [12195] ERROR:auth_db:get_ha1: failed to query database
-----------

I've two users registered (alice and bob), both registered in the same Twinkle sofphone.
- If alice calls (so OpenSIPS sends 407) the OpenSIPS returns 500 when alice re-sends the INVITE with credentials (auth_db issue clearly).
- If bob calls (OpenSIPS sends also 407) bob re-sends the INVITE with credentials and there is no problem.

After restarting OpenSIPS the issue dissapears (temporaly).

I've found similar problems, specially this thread:
  http://www.mail-archive.com/devel%40lists.openser.org/msg02761.html
in which Bogdan finally says:

---------
as the DB connections are TCP connections, if the connection is opened before the fork, it will inherited by all the forked child procs. This is a typical error if you mishandle a DB connection from mod_init().
---------

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

>Comment By: I?aki Baz (ibc_sf)
Date: 2009-02-17 17:38

Message:
About this problem I would like to clarify that I have two OpenSIPS running
in the same host:

- Proxy: running in 5060 and 5062.
- Presence Server: running in port 5070.

There are separated directories for each one (for example
/var/run/opensips and /var/run/opensips_presence).

Both share the same MySQL database ("opensips") in the same host, but I
think there are no shared tables.

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

Comment By: I?aki Baz (ibc_sf)
Date: 2009-02-16 00:47

Message:
Hi, after some days I've rechecked the logs and the error still occurs. The
server has *very low* traffic (just me when open my softphone with 3-4
accounts configured). The version I'm running now is 5190 and I attach a
log.
Note however that in this log it seems that the error is related to
presence_dialoginfo module (the PUBLISH is generated by pua_dialoginfo).
The proccess involve in the bug is 10277.
File Added: ERROR_db_mysql-rev5190.txt

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

Comment By: I?aki Baz (ibc_sf)
Date: 2009-01-21 19:40

Message:
The last error:
  ERROR:db_mysql:db_mysql_submit_query: driver error on query: Commands
out of sync; you can't run this command now
occurred in Jan 15, but I don't know which revision I was using (anyway a
modern one).

I'm compiling it against the trunk revision right now and will check. I
have full logs (level = 4) and store the logs in a file separated from
syslog so if the error occurs I'd have enough information.

I would like to tell something better but this is the best I have.

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

Comment By: Bogdan-Andrei Iancu (bogdan_iancu)
Date: 2009-01-21 14:25

Message:
Hi Inaki,

is this issue still actual after the latest presence fixes?

Regards,
Bogdan

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

Comment By: I?aki Baz (ibc_sf)
Date: 2008-12-15 20:25

Message:
After some checks I've realized that this bug is related to presence
module.

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

Comment By: I?aki Baz (ibc_sf)
Date: 2008-12-11 10:32

Message:
Sorry, forget it. The problem also occurs with "children=1".
I'm getting crazy :(

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

Comment By: I?aki Baz (ibc_sf)
Date: 2008-12-10 17:47

Message:
The ERROR just occurs when "children>1". Some tested cases:

1) OK
children=1
dissable_tcp=no
listen=MY_IP:MY_PORT

2) ERROR:db_mysql:db_mysql_submit_query
children=2
dissable_tcp=no
listen=MY_IP:MY_PORT

3) OK
children=1
dissable_tcp=no
listen=MY_IP:MY_PORT
listen=MY_IP:MY_PORT_2
listen=MY_IP_2:MY_PORT
listen=MY_IP_2:MY_PORT_2

4) ERROR:db_mysql:db_mysql_submit_query
children=2
dissable_tcp=no
listen=MY_IP:MY_PORT
listen=MY_IP:MY_PORT_2
listen=MY_IP_2:MY_PORT
listen=MY_IP_2:MY_PORT_2


This is, the error occurs VERY VERY often when "children>1", no matter how
many listening binds there are.


Also, as you can see in the following log, the error is related to the
MySQL driver, regardless of the OpenSIPS module:

---------
opensips[23846]: ERROR:db_mysql:db_mysql_submit_query: driver error on
query: Duplicate entry 'sip:bob at domain.net-bob-domain.net-presence'
for key 2
opensips[23846]: ERROR:core:db_do_insert: error while submitting query
opensips[23846]: ERROR:presence:update_presentity: inserting new
record in database
opensips[23846]: ERROR:presence:handle_publish: when updating presentity
opensips[23847]: ERROR:db_mysql:db_mysql_submit_query: driver error on
query: Commands out of sync; you can't run this command now
opensips[23847]: ERROR:core:db_do_query: error while submitting query
opensips[23847]: ERROR:presence:get_p_notify_body: failed to query
presentity table
opensips[23847]: ERROR:db_mysql:db_mysql_submit_query: driver error on
query: Commands out of sync; you can't run this command now
opensips[23847]: ERROR:core:db_do_query: error while submitting query
opensips[23847]: ERROR:auth_db:get_ha1: failed to query database
opensips[23847]: ERROR:db_mysql:db_mysql_submit_query: driver error on
query: Commands out of sync; you can't run this command now
opensips[23847]: ERROR:core:db_do_query: error while submitting query
opensips[23847]: ERROR:auth_db:get_ha1: failed to query database
opensips[23847]: ERROR:db_mysql:db_mysql_submit_query: driver error on
query: Commands out of sync; you can't run this command now
opensips[23847]: ERROR:core:db_do_delete: error while submitting query
opensips[23847]: ERROR:presence:delete_db_subs: sql delete failed
opensips[23847]: ERROR:db_mysql:db_mysql_submit_query: driver error on
query: Commands out of sync; you can't run this command now
opensips[23847]: ERROR:core:db_do_delete: error while submitting query
opensips[23847]: ERROR:presence:delete_db_subs: sql delete failed
opensips[23847]: ERROR:db_mysql:db_mysql_submit_query: driver error on
query: Commands out of sync; you can't run this command now
opensips[23847]: ERROR:core:db_do_delete: error while submitting query
opensips[23847]: ERROR:presence:delete_db_subs: sql delete failed
opensips[23847]: ERROR:db_mysql:db_mysql_submit_query: driver error on
query: Commands out of sync; you can't run this command now
opensips[23847]: ERROR:core:db_do_delete: error while submitting query
opensips[23847]: ERROR:presence:delete_db_subs: sql delete failed
opensips[23847]: ERROR:presence:update_subscription: deleting
subscription record from database
opensips[23847]: ERROR:presence:handle_subscribe: in update_subscription
opensips[23847]: ERROR:db_mysql:db_mysql_submit_query: driver error on
query: Commands out of sync; you can't run this command now
opensips[23847]: ERROR:core:db_do_delete: error while submitting query
opensips[23847]: ERROR:presence:delete_db_subs: sql delete failed
opensips[23847]: ERROR:presence:update_subscription: deleting
subscription record from database
opensips[23847]: ERROR:presence:handle_subscribe: in update_subscription
opensips[23847]: ERROR:db_mysql:db_mysql_submit_query: driver error on
query: Commands out of sync; you can't run this command now
opensips[23847]: ERROR:core:db_do_delete: error while submitting query
opensips[23847]: ERROR:presence:delete_db_subs: sql delete failed
opensips[23847]: ERROR:presence:update_subscription: deleting
subscription record from database
opensips[23847]: ERROR:presence:handle_subscribe: in update_subscription
opensips[23847]: ERROR:db_mysql:db_mysql_submit_query: driver error on
query: Commands out of sync; you can't run this command now
opensips[23847]: ERROR:core:db_do_delete: error while submitting query
opensips[23847]: ERROR:presence:delete_db_subs: sql delete failed
opensips[23847]: ERROR:presence:update_subscription: deleting
subscription record from database
opensips[23847]: ERROR:presence:handle_subscribe: in update_subscription
opensips[23847]: ERROR:db_mysql:db_mysql_submit_query: driver error on
query: Commands out of sync; you can't run this command now
opensips[23847]: ERROR:core:db_do_delete: error while submitting query
opensips[23847]: ERROR:presence:delete_db_subs: sql delete failed
opensips[23847]: ERROR:presence:update_subscription: deleting
subscription record from database
opensips[23847]: ERROR:presence:handle_subscribe: in update_subscription
opensips[23847]: ERROR:db_mysql:db_mysql_submit_query: driver error on
query: Commands out of sync; you can't run this command now
opensips[23847]: ERROR:core:db_do_delete: error while submitting query
opensips[23847]: ERROR:presence:delete_db_subs: sql delete failed
opensips[23847]: ERROR:presence:update_subscription: deleting
subscription record from database
opensips[23847]: ERROR:presence:handle_subscribe: in update_subscription
opensips[23847]: ERROR:db_mysql:db_mysql_submit_query: driver error on
query: Commands out of sync; you can't run this command now
opensips[23847]: ERROR:core:db_do_query: error while submitting query
opensips[23847]: ERROR:auth_db:get_ha1: failed to query database
opensips[23847]: ERROR:db_mysql:db_mysql_submit_query: driver error on
query: Commands out of sync; you can't run this command now
opensips[23847]: ERROR:core:db_do_query: error while submitting query
opensips[23847]: ERROR:auth_db:get_ha1: failed to query database
opensips[23847]: ERROR:db_mysql:db_mysql_submit_query: driver error on
query: Commands out of sync; you can't run this command now
opensips[23847]: ERROR:core:db_do_query: error while submitting query
opensips[23847]: ERROR:auth_db:get_ha1: failed to query database
opensips[23847]: ERROR:db_mysql:db_mysql_submit_query: driver error on
query: Commands out of sync; you can't run this command now
opensips[23847]: ERROR:core:db_do_query: error while submitting query
opensips[23847]: ERROR:auth_db:get_ha1: failed to query database
opensips[23847]: ERROR:db_mysql:db_mysql_submit_query: driver error on
query: Commands out of sync; you can't run this command now
opensips[23847]: ERROR:core:db_do_query: error while submitting query
opensips[23847]: ERROR:auth_db:get_ha1: failed to query database
----------

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

Comment By: I?aki Baz (ibc_sf)
Date: 2008-11-24 14:23

Message:
I use Debian Etch (64 bits) with OpenSIPS trunk version:

ii  libmysqlclient15-dev              5.0.32-7etch6
ii  libmysqlclient15off               5.0.32-7etch6
ii  mysql-client-5.0                  5.0.32-7etch6
ii  mysql-common                      5.0.32-7etch6
ii  mysql-server-5.0                  5.0.32-7etch6
ii  opensips-mysql-module             1.4.0-1

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

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


From bogdan at voice-system.ro  Tue Feb 17 17:40:46 2009
From: bogdan at voice-system.ro (Bogdan-Andrei Iancu)
Date: Tue, 17 Feb 2009 18:40:46 +0200
Subject: [OpenSIPS-Devel] [MI] - flush support
Message-ID: <499AE88E.3020209@voice-system.ro>

Hi,

Last week I added in OpenSIPS 1.5 an extension to MI (Management 
Interface) that allow a module to flush partial MI replies to the 
transport layer.

This extension wants to fix a bug/limitation from previous versions: 
trying to print a large amount of data from OpenSIPS to the outside.

Ex: opensipsctl ul show  may fail if you have a large number of 
subscribers registered, because the private memory is not enough for 
building the list with all the subscriber, so this command may 
consistently fail

There is the same for other commands like listing the dialogs.


With the new extension, the reply data is transfered in chunks 
(periodically flushed) to the transport layer, so the available memory 
will not be a limitation.

So, in OpenSIPS 1.5, the Management Interface has no limitation when 
comes in transfering large amounts of data (registered users, dialogs, 
etc). This allow the smooth size scaling of OpenSIPS without any penalties.

Regards,
Bogdan


From noreply at sourceforge.net  Tue Feb 17 17:41:01 2009
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 17 Feb 2009 16:41:01 +0000
Subject: [OpenSIPS-Devel] [ opensips-Bugs-2335003 ]
	ERROR:db_mysql:db_mysql_submit_query
Message-ID: <E1LZT0H-000799-5h@665xhf1.ch3.sourceforge.com>

Bugs item #2335003, was opened at 2008-11-23 22:54
Message generated for change (Comment added) made by ibc_sf
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=2335003&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: 1
Private: No
Submitted By: I?aki Baz (ibc_sf)
Assigned to: Nobody/Anonymous (nobody)
Summary: ERROR:db_mysql:db_mysql_submit_query

Initial Comment:
This error occurs to me very often (sometimes during an INVITE, during a SUBSCRIBE...). If it occurs during an INVITE, then OpenSIPS returns 500:

-----------
Nov 23 16:42:07 [12195] ERROR:db_mysql:db_mysql_submit_query: driver error on 
query: Commands out of sync; you can't run this command now
Nov 23 16:42:07 [12195] ERROR:core:db_do_query: error while submitting query
Nov 23 16:42:07 [12195] ERROR:auth_db:get_ha1: failed to query database
-----------

I've two users registered (alice and bob), both registered in the same Twinkle sofphone.
- If alice calls (so OpenSIPS sends 407) the OpenSIPS returns 500 when alice re-sends the INVITE with credentials (auth_db issue clearly).
- If bob calls (OpenSIPS sends also 407) bob re-sends the INVITE with credentials and there is no problem.

After restarting OpenSIPS the issue dissapears (temporaly).

I've found similar problems, specially this thread:
  http://www.mail-archive.com/devel%40lists.openser.org/msg02761.html
in which Bogdan finally says:

---------
as the DB connections are TCP connections, if the connection is opened before the fork, it will inherited by all the forked child procs. This is a typical error if you mishandle a DB connection from mod_init().
---------

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

>Comment By: I?aki Baz (ibc_sf)
Date: 2009-02-17 17:41

Message:
Sorry, it is:
- Proxy: running in 5060 and 5062.
- Presence Server: running in port 5065.

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

Comment By: I?aki Baz (ibc_sf)
Date: 2009-02-17 17:38

Message:
About this problem I would like to clarify that I have two OpenSIPS running
in the same host:

- Proxy: running in 5060 and 5062.
- Presence Server: running in port 5070.

There are separated directories for each one (for example
/var/run/opensips and /var/run/opensips_presence).

Both share the same MySQL database ("opensips") in the same host, but I
think there are no shared tables.

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

Comment By: I?aki Baz (ibc_sf)
Date: 2009-02-16 00:47

Message:
Hi, after some days I've rechecked the logs and the error still occurs. The
server has *very low* traffic (just me when open my softphone with 3-4
accounts configured). The version I'm running now is 5190 and I attach a
log.
Note however that in this log it seems that the error is related to
presence_dialoginfo module (the PUBLISH is generated by pua_dialoginfo).
The proccess involve in the bug is 10277.
File Added: ERROR_db_mysql-rev5190.txt

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

Comment By: I?aki Baz (ibc_sf)
Date: 2009-01-21 19:40

Message:
The last error:
  ERROR:db_mysql:db_mysql_submit_query: driver error on query: Commands
out of sync; you can't run this command now
occurred in Jan 15, but I don't know which revision I was using (anyway a
modern one).

I'm compiling it against the trunk revision right now and will check. I
have full logs (level = 4) and store the logs in a file separated from
syslog so if the error occurs I'd have enough information.

I would like to tell something better but this is the best I have.

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

Comment By: Bogdan-Andrei Iancu (bogdan_iancu)
Date: 2009-01-21 14:25

Message:
Hi Inaki,

is this issue still actual after the latest presence fixes?

Regards,
Bogdan

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

Comment By: I?aki Baz (ibc_sf)
Date: 2008-12-15 20:25

Message:
After some checks I've realized that this bug is related to presence
module.

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

Comment By: I?aki Baz (ibc_sf)
Date: 2008-12-11 10:32

Message:
Sorry, forget it. The problem also occurs with "children=1".
I'm getting crazy :(

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

Comment By: I?aki Baz (ibc_sf)
Date: 2008-12-10 17:47

Message:
The ERROR just occurs when "children>1". Some tested cases:

1) OK
children=1
dissable_tcp=no
listen=MY_IP:MY_PORT

2) ERROR:db_mysql:db_mysql_submit_query
children=2
dissable_tcp=no
listen=MY_IP:MY_PORT

3) OK
children=1
dissable_tcp=no
listen=MY_IP:MY_PORT
listen=MY_IP:MY_PORT_2
listen=MY_IP_2:MY_PORT
listen=MY_IP_2:MY_PORT_2

4) ERROR:db_mysql:db_mysql_submit_query
children=2
dissable_tcp=no
listen=MY_IP:MY_PORT
listen=MY_IP:MY_PORT_2
listen=MY_IP_2:MY_PORT
listen=MY_IP_2:MY_PORT_2


This is, the error occurs VERY VERY often when "children>1", no matter how
many listening binds there are.


Also, as you can see in the following log, the error is related to the
MySQL driver, regardless of the OpenSIPS module:

---------
opensips[23846]: ERROR:db_mysql:db_mysql_submit_query: driver error on
query: Duplicate entry 'sip:bob at domain.net-bob-domain.net-presence'
for key 2
opensips[23846]: ERROR:core:db_do_insert: error while submitting query
opensips[23846]: ERROR:presence:update_presentity: inserting new
record in database
opensips[23846]: ERROR:presence:handle_publish: when updating presentity
opensips[23847]: ERROR:db_mysql:db_mysql_submit_query: driver error on
query: Commands out of sync; you can't run this command now
opensips[23847]: ERROR:core:db_do_query: error while submitting query
opensips[23847]: ERROR:presence:get_p_notify_body: failed to query
presentity table
opensips[23847]: ERROR:db_mysql:db_mysql_submit_query: driver error on
query: Commands out of sync; you can't run this command now
opensips[23847]: ERROR:core:db_do_query: error while submitting query
opensips[23847]: ERROR:auth_db:get_ha1: failed to query database
opensips[23847]: ERROR:db_mysql:db_mysql_submit_query: driver error on
query: Commands out of sync; you can't run this command now
opensips[23847]: ERROR:core:db_do_query: error while submitting query
opensips[23847]: ERROR:auth_db:get_ha1: failed to query database
opensips[23847]: ERROR:db_mysql:db_mysql_submit_query: driver error on
query: Commands out of sync; you can't run this command now
opensips[23847]: ERROR:core:db_do_delete: error while submitting query
opensips[23847]: ERROR:presence:delete_db_subs: sql delete failed
opensips[23847]: ERROR:db_mysql:db_mysql_submit_query: driver error on
query: Commands out of sync; you can't run this command now
opensips[23847]: ERROR:core:db_do_delete: error while submitting query
opensips[23847]: ERROR:presence:delete_db_subs: sql delete failed
opensips[23847]: ERROR:db_mysql:db_mysql_submit_query: driver error on
query: Commands out of sync; you can't run this command now
opensips[23847]: ERROR:core:db_do_delete: error while submitting query
opensips[23847]: ERROR:presence:delete_db_subs: sql delete failed
opensips[23847]: ERROR:db_mysql:db_mysql_submit_query: driver error on
query: Commands out of sync; you can't run this command now
opensips[23847]: ERROR:core:db_do_delete: error while submitting query
opensips[23847]: ERROR:presence:delete_db_subs: sql delete failed
opensips[23847]: ERROR:presence:update_subscription: deleting
subscription record from database
opensips[23847]: ERROR:presence:handle_subscribe: in update_subscription
opensips[23847]: ERROR:db_mysql:db_mysql_submit_query: driver error on
query: Commands out of sync; you can't run this command now
opensips[23847]: ERROR:core:db_do_delete: error while submitting query
opensips[23847]: ERROR:presence:delete_db_subs: sql delete failed
opensips[23847]: ERROR:presence:update_subscription: deleting
subscription record from database
opensips[23847]: ERROR:presence:handle_subscribe: in update_subscription
opensips[23847]: ERROR:db_mysql:db_mysql_submit_query: driver error on
query: Commands out of sync; you can't run this command now
opensips[23847]: ERROR:core:db_do_delete: error while submitting query
opensips[23847]: ERROR:presence:delete_db_subs: sql delete failed
opensips[23847]: ERROR:presence:update_subscription: deleting
subscription record from database
opensips[23847]: ERROR:presence:handle_subscribe: in update_subscription
opensips[23847]: ERROR:db_mysql:db_mysql_submit_query: driver error on
query: Commands out of sync; you can't run this command now
opensips[23847]: ERROR:core:db_do_delete: error while submitting query
opensips[23847]: ERROR:presence:delete_db_subs: sql delete failed
opensips[23847]: ERROR:presence:update_subscription: deleting
subscription record from database
opensips[23847]: ERROR:presence:handle_subscribe: in update_subscription
opensips[23847]: ERROR:db_mysql:db_mysql_submit_query: driver error on
query: Commands out of sync; you can't run this command now
opensips[23847]: ERROR:core:db_do_delete: error while submitting query
opensips[23847]: ERROR:presence:delete_db_subs: sql delete failed
opensips[23847]: ERROR:presence:update_subscription: deleting
subscription record from database
opensips[23847]: ERROR:presence:handle_subscribe: in update_subscription
opensips[23847]: ERROR:db_mysql:db_mysql_submit_query: driver error on
query: Commands out of sync; you can't run this command now
opensips[23847]: ERROR:core:db_do_delete: error while submitting query
opensips[23847]: ERROR:presence:delete_db_subs: sql delete failed
opensips[23847]: ERROR:presence:update_subscription: deleting
subscription record from database
opensips[23847]: ERROR:presence:handle_subscribe: in update_subscription
opensips[23847]: ERROR:db_mysql:db_mysql_submit_query: driver error on
query: Commands out of sync; you can't run this command now
opensips[23847]: ERROR:core:db_do_query: error while submitting query
opensips[23847]: ERROR:auth_db:get_ha1: failed to query database
opensips[23847]: ERROR:db_mysql:db_mysql_submit_query: driver error on
query: Commands out of sync; you can't run this command now
opensips[23847]: ERROR:core:db_do_query: error while submitting query
opensips[23847]: ERROR:auth_db:get_ha1: failed to query database
opensips[23847]: ERROR:db_mysql:db_mysql_submit_query: driver error on
query: Commands out of sync; you can't run this command now
opensips[23847]: ERROR:core:db_do_query: error while submitting query
opensips[23847]: ERROR:auth_db:get_ha1: failed to query database
opensips[23847]: ERROR:db_mysql:db_mysql_submit_query: driver error on
query: Commands out of sync; you can't run this command now
opensips[23847]: ERROR:core:db_do_query: error while submitting query
opensips[23847]: ERROR:auth_db:get_ha1: failed to query database
opensips[23847]: ERROR:db_mysql:db_mysql_submit_query: driver error on
query: Commands out of sync; you can't run this command now
opensips[23847]: ERROR:core:db_do_query: error while submitting query
opensips[23847]: ERROR:auth_db:get_ha1: failed to query database
----------

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

Comment By: I?aki Baz (ibc_sf)
Date: 2008-11-24 14:23

Message:
I use Debian Etch (64 bits) with OpenSIPS trunk version:

ii  libmysqlclient15-dev              5.0.32-7etch6
ii  libmysqlclient15off               5.0.32-7etch6
ii  mysql-client-5.0                  5.0.32-7etch6
ii  mysql-common                      5.0.32-7etch6
ii  mysql-server-5.0                  5.0.32-7etch6
ii  opensips-mysql-module             1.4.0-1

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

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


From ibc at aliax.net  Tue Feb 17 17:55:48 2009
From: ibc at aliax.net (=?UTF-8?Q?I=C3=B1aki_Baz_Castillo?=)
Date: Tue, 17 Feb 2009 17:55:48 +0100
Subject: [OpenSIPS-Devel] [MI] - flush support
In-Reply-To: <499AE88E.3020209@voice-system.ro>
References: <499AE88E.3020209@voice-system.ro>
Message-ID: <cc1f582e0902170855v6269661frb4c691aeb51eb2a@mail.gmail.com>

2009/2/17 Bogdan-Andrei Iancu <bogdan at voice-system.ro>:
> Hi,
>
> Last week I added in OpenSIPS 1.5 an extension to MI (Management
> Interface) that allow a module to flush partial MI replies to the
> transport layer.
>
> This extension wants to fix a bug/limitation from previous versions:
> trying to print a large amount of data from OpenSIPS to the outside.
>
> Ex: opensipsctl ul show  may fail if you have a large number of
> subscribers registered, because the private memory is not enough for
> building the list with all the subscriber, so this command may
> consistently fail
>
> There is the same for other commands like listing the dialogs.
>
>
> With the new extension, the reply data is transfered in chunks
> (periodically flushed) to the transport layer, so the available memory
> will not be a limitation.
>
> So, in OpenSIPS 1.5, the Management Interface has no limitation when
> comes in transfering large amounts of data (registered users, dialogs,
> etc). This allow the smooth size scaling of OpenSIPS without any penalties.

Great news :)

-- 
I?aki Baz Castillo
<ibc at aliax.net>


From bogdan at voice-system.ro  Tue Feb 17 19:18:18 2009
From: bogdan at voice-system.ro (Bogdan-Andrei Iancu)
Date: Tue, 17 Feb 2009 18:18:18 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[5328]
	trunk/modules/load_balancer
Message-ID: <E1LZUWQ-0004NP-N0@bj8yhf1.ch3.sourceforge.com>

Revision: 5328
          http://opensips.svn.sourceforge.net/opensips/?rev=5328&view=rev
Author:   bogdan_iancu
Date:     2009-02-17 18:18:18 +0000 (Tue, 17 Feb 2009)

Log Message:
-----------
- docs (first version) added

Added Paths:
-----------
    trunk/modules/load_balancer/doc/
    trunk/modules/load_balancer/doc/load_balancer.xml
    trunk/modules/load_balancer/doc/load_balancer_admin.xml
    trunk/modules/load_balancer/doc/load_balancer_devel.xml
    trunk/modules/load_balancer/doc/load_balancer_faq.xml


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


From noreply at sourceforge.net  Wed Feb 18 02:41:36 2009
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 18 Feb 2009 01:41:36 +0000
Subject: [OpenSIPS-Devel] [ opensips-Feature Requests-2610968 ] Add
	attributes to trusted IP
Message-ID: <E1LZbRQ-0003k4-FC@1bkjzd1.ch3.sourceforge.com>

Feature Requests item #2610968, was opened at 2009-02-17 20:41
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086413&aid=2610968&group_id=232389

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: modules
Group: None
Status: Open
Priority: 5
Private: No
Submitted By: Brett Nemeroff (brettnem)
Assigned to: Nobody/Anonymous (nobody)
Summary: Add attributes to trusted IP

Initial Comment:
I find myself needing this a lot. Basically,I IP authenticate an inbound request, but I want to set AVPs when that happens automagically. 

For example, how many allowed sessions per IP, or a callerid to be used.



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

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


From dan at ag-projects.com  Wed Feb 18 06:15:05 2009
From: dan at ag-projects.com (Dan Pascu)
Date: Wed, 18 Feb 2009 07:15:05 +0200
Subject: [OpenSIPS-Devel]
	=?iso-8859-1?q?Is_it_possible_to_commit_new_=22r?=
	=?iso-8859-1?q?egex=22_module_before=091=2E5=3F?=
In-Reply-To: <499AB33F.2050606@voice-system.ro>
References: <200902170041.29072.ibc@aliax.net>
	<499AB33F.2050606@voice-system.ro>
Message-ID: <200902180715.05677.dan@ag-projects.com>

On Tuesday 17 February 2009, Bogdan-Andrei Iancu wrote:
> Hi I?aki,
>
> Personally I think we can make an exception, given the circumstances.
> If the new code is tested and does not affect the overall stability of
> the code (which is the most important think here), we can be a bit
> flexible and go for it.
>
> I'm also interested in hearing other people opinion on this.

I see no harm in adding it. It's a standalone module so it can't affect 
the rest of the code. Besides it was an issue of timing to push it into 
svn and a 1 day delay it's not that big of an issue.

>
> IMHO the important is the goal and not the rules to get to the goal
> :D......
>
> Regards,
> Bogdan
>
> I?aki Baz Castillo wrote:
> > Hi, I planned to commit a new module called "Regex" in SVN trunk but
> > I was away these last days and couldn't submit it before the SVN
> > freeze (yesterday).
> >
> > I know that no new code should be submitted in this moment, but this
> > module is already tested and working in Kamailio (and of course I've
> > also checked it in OpenSIPS trunk version). For now there are no
> > bugs/issues with it.
> >
> > Would you, developers, accept this module now or should I wait until
> > 1.5 is released?
> >
> > Thanks and best regards.
> >
> >
> > PD: Regex module documentation in Kamailio:
> >       http://kamailio.org/docs/modules/devel/regex.html
>
> _______________________________________________
> Devel mailing list
> Devel at lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/devel



-- 
Dan


From ibc at aliax.net  Wed Feb 18 09:44:38 2009
From: ibc at aliax.net (=?UTF-8?Q?I=C3=B1aki_Baz_Castillo?=)
Date: Wed, 18 Feb 2009 09:44:38 +0100
Subject: [OpenSIPS-Devel] Is it possible to commit new "regex" module
	before 1.5?
In-Reply-To: <200902180715.05677.dan@ag-projects.com>
References: <200902170041.29072.ibc@aliax.net>
	<499AB33F.2050606@voice-system.ro>
	<200902180715.05677.dan@ag-projects.com>
Message-ID: <cc1f582e0902180044v2ddb3106u343b275d1985c76@mail.gmail.com>

2009/2/18 Dan Pascu <dan at ag-projects.com>:
> On Tuesday 17 February 2009, Bogdan-Andrei Iancu wrote:
>> Hi I?aki,
>>
>> Personally I think we can make an exception, given the circumstances.
>> If the new code is tested and does not affect the overall stability of
>> the code (which is the most important think here), we can be a bit
>> flexible and go for it.
>>
>> I'm also interested in hearing other people opinion on this.
>
> I see no harm in adding it. It's a standalone module so it can't affect
> the rest of the code. Besides it was an issue of timing to push it into
> svn and a 1 day delay it's not that big of an issue.

Thanks to all, I will submit it today.

Best regards.

-- 
I?aki Baz Castillo
<ibc at aliax.net>


From bogdan at voice-system.ro  Wed Feb 18 10:48:21 2009
From: bogdan at voice-system.ro (Bogdan-Andrei Iancu)
Date: Wed, 18 Feb 2009 11:48:21 +0200
Subject: [OpenSIPS-Devel] Is it possible to commit new "regex" module
 before 1.5?
In-Reply-To: <cc1f582e0902180044v2ddb3106u343b275d1985c76@mail.gmail.com>
References: <200902170041.29072.ibc@aliax.net>	<499AB33F.2050606@voice-system.ro>	<200902180715.05677.dan@ag-projects.com>
	<cc1f582e0902180044v2ddb3106u343b275d1985c76@mail.gmail.com>
Message-ID: <499BD965.80601@voice-system.ro>

Hi Inaki,

Please proceed - I want to have the final update list of all the changes 
in 1.5 ready :)

Thanks and regards,
Bogdan

I?aki Baz Castillo wrote:
> 2009/2/18 Dan Pascu <dan at ag-projects.com>:
>   
>> On Tuesday 17 February 2009, Bogdan-Andrei Iancu wrote:
>>     
>>> Hi I?aki,
>>>
>>> Personally I think we can make an exception, given the circumstances.
>>> If the new code is tested and does not affect the overall stability of
>>> the code (which is the most important think here), we can be a bit
>>> flexible and go for it.
>>>
>>> I'm also interested in hearing other people opinion on this.
>>>       
>> I see no harm in adding it. It's a standalone module so it can't affect
>> the rest of the code. Besides it was an issue of timing to push it into
>> svn and a 1 day delay it's not that big of an issue.
>>     
>
> Thanks to all, I will submit it today.
>
> Best regards.
>
>   



From ibc at aliax.net  Wed Feb 18 11:18:31 2009
From: ibc at aliax.net (=?UTF-8?Q?I=F1aki_Baz_Castillo?=)
Date: Wed, 18 Feb 2009 10:18:31 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[5329] trunk/modules
Message-ID: <E1LZjVf-0006CX-P3@74yxhf1.ch3.sourceforge.com>

Revision: 5329
          http://opensips.svn.sourceforge.net/opensips/?rev=5329&view=rev
Author:   ibc_sf
Date:     2009-02-18 10:18:31 +0000 (Wed, 18 Feb 2009)

Log Message:
-----------
- First commit of Regex module

Added Paths:
-----------
    trunk/modules/regex/
    trunk/modules/regex/Makefile
    trunk/modules/regex/README
    trunk/modules/regex/doc/
    trunk/modules/regex/doc/regex.xml
    trunk/modules/regex/doc/regex_admin.xml
    trunk/modules/regex/regex_mod.c


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


From ibc at aliax.net  Wed Feb 18 11:26:40 2009
From: ibc at aliax.net (=?UTF-8?Q?I=C3=B1aki_Baz_Castillo?=)
Date: Wed, 18 Feb 2009 11:26:40 +0100
Subject: [OpenSIPS-Devel] Is it possible to commit new "regex" module
	before 1.5?
In-Reply-To: <499BD965.80601@voice-system.ro>
References: <200902170041.29072.ibc@aliax.net>
	<499AB33F.2050606@voice-system.ro>
	<200902180715.05677.dan@ag-projects.com>
	<cc1f582e0902180044v2ddb3106u343b275d1985c76@mail.gmail.com>
	<499BD965.80601@voice-system.ro>
Message-ID: <cc1f582e0902180226l1d13734btb91c5abcd8aead42@mail.gmail.com>

2009/2/18 Bogdan-Andrei Iancu <bogdan at voice-system.ro>:
> Hi Inaki,
>
> Please proceed - I want to have the final update list of all the changes in
> 1.5 ready :)

Already commited. I just forgot to set:
  svn propset svn:keywords "Author Date Id Revision"
in some files.

I've already added it in my local repository but I don't know how to
submit those changes. Must I modify the files?

Thanks.

-- 
I?aki Baz Castillo
<ibc at aliax.net>


From ibc at aliax.net  Wed Feb 18 11:32:45 2009
From: ibc at aliax.net (=?UTF-8?Q?I=C3=B1aki_Baz_Castillo?=)
Date: Wed, 18 Feb 2009 11:32:45 +0100
Subject: [OpenSIPS-Devel] Is it possible to commit new "regex" module
	before 1.5?
In-Reply-To: <cc1f582e0902180226l1d13734btb91c5abcd8aead42@mail.gmail.com>
References: <200902170041.29072.ibc@aliax.net>
	<499AB33F.2050606@voice-system.ro>
	<200902180715.05677.dan@ag-projects.com>
	<cc1f582e0902180044v2ddb3106u343b275d1985c76@mail.gmail.com>
	<499BD965.80601@voice-system.ro>
	<cc1f582e0902180226l1d13734btb91c5abcd8aead42@mail.gmail.com>
Message-ID: <cc1f582e0902180232y5d49f41eu84cab63c5d84275@mail.gmail.com>

2009/2/18 I?aki Baz Castillo <ibc at aliax.net>:
> Already commited. I just forgot to set:
>  svn propset svn:keywords "Author Date Id Revision"
> in some files.
>
> I've already added it in my local repository but I don't know how to
> submit those changes. Must I modify the files?

Ok, when doing a "svn co" the keywords "Date", "Author" and so are
correctly filled, so it's ok now. I expect that "svn ci" after "svn
propset svn:keywords "Author Date Id Revision" FILE" did work.

Regards.


-- 
I?aki Baz Castillo
<ibc at aliax.net>


From ibc at aliax.net  Wed Feb 18 11:35:36 2009
From: ibc at aliax.net (=?UTF-8?Q?I=F1aki_Baz_Castillo?=)
Date: Wed, 18 Feb 2009 10:35:36 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[5330]
	trunk/modules/regex/README
Message-ID: <E1LZjmC-0006pH-Pu@74yxhf1.ch3.sourceforge.com>

Revision: 5330
          http://opensips.svn.sourceforge.net/opensips/?rev=5330&view=rev
Author:   ibc_sf
Date:     2009-02-18 10:35:36 +0000 (Wed, 18 Feb 2009)

Log Message:
-----------
- Added svn keywords to README

Modified Paths:
--------------
    trunk/modules/regex/README

Property Changed:
----------------
    trunk/modules/regex/README


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


From bogdan at voice-system.ro  Wed Feb 18 14:07:13 2009
From: bogdan at voice-system.ro (Bogdan-Andrei Iancu)
Date: Wed, 18 Feb 2009 15:07:13 +0200
Subject: [OpenSIPS-Devel] Is it possible to commit new "regex" module
 before 1.5?
In-Reply-To: <cc1f582e0902180226l1d13734btb91c5abcd8aead42@mail.gmail.com>
References: <200902170041.29072.ibc@aliax.net>	
	<499AB33F.2050606@voice-system.ro>	
	<200902180715.05677.dan@ag-projects.com>	
	<cc1f582e0902180044v2ddb3106u343b275d1985c76@mail.gmail.com>	
	<499BD965.80601@voice-system.ro>
	<cc1f582e0902180226l1d13734btb91c5abcd8aead42@mail.gmail.com>
Message-ID: <499C0801.9030704@voice-system.ro>

I?aki Baz Castillo wrote:
> 2009/2/18 Bogdan-Andrei Iancu <bogdan at voice-system.ro>:
>   
>> Hi Inaki,
>>
>> Please proceed - I want to have the final update list of all the changes in
>> 1.5 ready :)
>>     
>
> Already commited. 
Perfect - thank you
> I just forgot to set:
>   svn propset svn:keywords "Author Date Id Revision"
> in some files.
>   
you can do it anytime
> I've already added it in my local repository but I don't know how to
> submit those changes. Must I modify the files?
>   
set the property and simply commit - it should do the work ;)

BTW, I fixed (hopefully) your display name in the commit 
notifications....Sorry about that :)


Regards,
Bogdan



From noreply at sourceforge.net  Wed Feb 18 14:11:41 2009
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 18 Feb 2009 13:11:41 +0000
Subject: [OpenSIPS-Devel] [ opensips-Bugs-2608188 ] OpenSIPS latest trunk
	libmysqlclient segfault
Message-ID: <E1LZmDF-0002t1-LM@d45xhf1.ch3.sourceforge.com>

Bugs item #2608188, was opened at 2009-02-17 11:47
Message generated for change (Comment added) made by omthapa
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=2608188&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: Accepted
Priority: 8
Private: No
Submitted By: Om Bikram Thapa (omthapa)
Assigned to: Bogdan-Andrei Iancu (bogdan_iancu)
Summary: OpenSIPS latest trunk libmysqlclient segfault 

Initial Comment:
OpenSIPS latest trunk on Debian Lenny/AMD64 dies with libmysqlclient segfault after a MySQL restart. The event that triggers this crash is registration related database query immediately after a MySQL restart. Once OpenSIPS is restarted after a crash, everything runs fine until next MySQL restart.

The log shows:

"opensips[16769]: segfault at 4c8 ip 7f36728bf283 sp 7fff7ba11a90 error 4 in libmysqlclient.so.15.0.0[7f3672862000+1bf000]"
 
and gdb bt gives following results:

---------------
Program terminated with signal 11, Segmentation fault.
[New process 16769]
#0  0x00007f36728bf283 in mysql_stmt_result_metadata ()
   from /usr/lib/libmysqlclient.so.15
(gdb) bt
#0  0x00007f36728bf283 in mysql_stmt_result_metadata ()
   from /usr/lib/libmysqlclient.so.15
#1  0x00007f3672c707b7 in db_mysql_do_prepared_query (conn=0x78b278, 
    query=<value optimized out>, v=0x7fff7ba11d20, n=1, uv=0x0, un=0)
    at dbase.c:363
#2  0x00007f3672c72e1f in db_mysql_query (_h=0x78b278, 
    _k=<value optimized out>, _op=<value optimized out>, _v=0x7fff7ba11d20, 
    _c=<value optimized out>, _n=1, _nc=2, _o=0x0, _r=0x7fff7ba11dc0)
    at dbase.c:591
#3  0x00007f366f3f0398 in authorize (_m=0x78fe98, 
    _realm=<value optimized out>, _table=<value optimized out>, 
    _hftype=<value optimized out>) at authorize.c:107
#4  0x000000000040f869 in do_action (a=0x780a48, msg=0x78fe98) at action.c:961
#5  0x000000000040e7e5 in run_action_list (a=<value optimized out>, 
    msg=0x78fe98) at action.c:139
#6  0x000000000046f194 in eval_elem (e=0x780b18, msg=0x78fe98, val=0x0)
    at route.c:1189
#7  0x00000000004708ed in eval_expr (e=0x120b1e0, msg=0x78fe98, val=0x0)
    at route.c:1486
#8  0x000000000047089c in eval_expr (e=0x780b60, msg=0x78fe98, val=0x0)
    at route.c:1502
#9  0x00000000004708c5 in eval_expr (e=0x780ba8, msg=0x78fe98, val=0x0)
    at route.c:1507
---Type <return> to continue, or q <return> to quit---
#10 0x000000000040f91c in do_action (a=0x780f40, msg=0x78fe98) at action.c:688
#11 0x000000000040e7e5 in run_action_list (a=<value optimized out>, 
    msg=0x78fe98) at action.c:139
#12 0x00000000004114d3 in do_action (a=0x781eb0, msg=0x78fe98) at action.c:705
#13 0x000000000040e7e5 in run_action_list (a=<value optimized out>, 
    msg=0x78fe98) at action.c:139
#14 0x0000000000410e07 in do_action (a=0x77ee88, msg=0x78fe98) at action.c:119
#15 0x000000000040e7e5 in run_action_list (a=<value optimized out>, 
    msg=0x78fe98) at action.c:139
#16 0x00000000004114d3 in do_action (a=0x77f028, msg=0x78fe98) at action.c:705
#17 0x000000000040e7e5 in run_action_list (a=<value optimized out>, 
    msg=0x78fe98) at action.c:139
#18 0x00000000004125fe in run_top_route (a=0x777e78, msg=0x78fe98)
    at action.c:119
#19 0x000000000045e898 in receive_msg (
    buf=0x749180 "REGISTER sip:x.x.x.x SIP/2.0\r\nCSeq: 2 REGISTER\r\nVia: SIP/2.0/UDP x.x.x.x:5061;branch=z9hG4bK60f1b2dd-57fa-dd11-9401-0015c5404858;rport\r\nUser-Agent: Ekiga/2.0.12\r\nAuthorization: Dige"..., 
    len=749, rcv_info=0x7fff7ba13530) at receive.c:165
#20 0x000000000049d3a6 in udp_rcv_loop () at udp_server.c:449
#21 0x00000000004291fb in main (argc=<value optimized out>, 
    argv=0x7fff7ba13718) at main.c:778
----------------


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

>Comment By: Om Bikram Thapa (omthapa)
Date: 2009-02-18 18:56

Message:
I modified domain in opensips domain table, immediately after that the
server crashed upon registration event with log  general protection
ip:7f249016986c sp:7fff992bf320 error:0 in
libmysqlclient.so.15.0.0[7f2490110000+1bf000]" and gdb backtrace now points
to different code:

----------
#0  0x00007f7a4c26f86c in mysql_stmt_fetch () from
/usr/lib/libmysqlclient.so.15
#1  0x00007f7a4c628a48 in db_mysql_convert_result (_h=0x78b278,
_r=0x78ba28) at res.c:161
#2  0x00007f7a4c626aaa in db_mysql_store_result (_h=0x78b278,
_r=0x7fff553c5770) at dbase.c:513
#3  0x00007f7a4c626e39 in db_mysql_query (_h=0x78b278, _k=<value optimized
out>, _op=<value optimized out>, _v=0x7fff553c56d0, _c=<value optimized
out>,
    _n=1, _nc=2, _o=0x0, _r=0x7fff553c5770) at dbase.c:593
#4  0x00007f7a48da4398 in authorize (_m=0x78fe98, _realm=<value optimized
out>, _table=<value optimized out>, _hftype=<value optimized out>)
    at authorize.c:107
#5  0x000000000040f869 in do_action (a=0x780a48, msg=0x78fe98) at
action.c:961
#6  0x000000000040e7e5 in run_action_list (a=<value optimized out>,
msg=0x78fe98) at action.c:139
#7  0x000000000046f194 in eval_elem (e=0x780b18, msg=0x78fe98, val=0x20)
at route.c:1189
#8  0x00000000004708ed in eval_expr (e=0xe543d0, msg=0x78fe98, val=0x0) at
route.c:1486
#9  0x000000000047089c in eval_expr (e=0x780b60, msg=0x78fe98, val=0x0) at
route.c:1502
#10 0x00000000004708c5 in eval_expr (e=0x780ba8, msg=0x78fe98, val=0x0) at
route.c:1507
#11 0x000000000040f91c in do_action (a=0x780f40, msg=0x78fe98) at
action.c:688
#12 0x000000000040e7e5 in run_action_list (a=<value optimized out>,
msg=0x78fe98) at action.c:139
#13 0x00000000004114d3 in do_action (a=0x781eb0, msg=0x78fe98) at
action.c:705
#14 0x000000000040e7e5 in run_action_list (a=<value optimized out>,
msg=0x78fe98) at action.c:139
#15 0x0000000000410e07 in do_action (a=0x77ee88, msg=0x78fe98) at
action.c:119
#16 0x000000000040e7e5 in run_action_list (a=<value optimized out>,
msg=0x78fe98) at action.c:139
#17 0x00000000004114d3 in do_action (a=0x77f028, msg=0x78fe98) at
action.c:705
#18 0x000000000040e7e5 in run_action_list (a=<value optimized out>,
msg=0x78fe98) at action.c:139
#19 0x00000000004125fe in run_top_route (a=0x777e78, msg=0x78fe98) at
action.c:119
#20 0x000000000045e898 in receive_msg (
    buf=0x749180 "REGISTER sip:x.x.x.x;transport=UDP SIP/2.0\r\nVia:
SIP/2.0/UDP
x.x.x.x:5060;branch=z9hG4bKgcjsr9edklicvlhif2tfvub;rport\r\nFrom:
<sip:300000 at x.x."..., len=693, rcv_info=0x7fff553c6ee0) at receive.c:165
#21 0x000000000049d3a6 in udp_rcv_loop () at udp_server.c:449
#22 0x00000000004291fb in main (argc=<value optimized out>,
argv=0x7fff553c70c8) at main.c:778
-----------------

I think this crash is also related to the same issue.

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

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


From anca at opensips.org  Wed Feb 18 15:23:55 2009
From: anca at opensips.org (Anca Vamanu)
Date: Wed, 18 Feb 2009 14:23:55 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[5331] trunk/modules/presence
Message-ID: <E1LZnL9-0008JC-AH@dn4whf1.ch3.sourceforge.com>

Revision: 5331
          http://opensips.svn.sourceforge.net/opensips/?rev=5331&view=rev
Author:   anca_vamanu
Date:     2009-02-18 14:23:54 +0000 (Wed, 18 Feb 2009)

Log Message:
-----------
- took out some prepare statemets usages that caused problems
- fixed database operations when fallback2db is set

Modified Paths:
--------------
    trunk/modules/presence/hash.c
    trunk/modules/presence/notify.c
    trunk/modules/presence/presentity.c
    trunk/modules/presence/subscribe.c


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


From saguti at gmail.com  Wed Feb 18 15:32:57 2009
From: saguti at gmail.com (Sergio Gutierrez)
Date: Wed, 18 Feb 2009 14:32:57 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[5332]
	trunk/modules/regex/Makefile
Message-ID: <E1LZnTt-0006ba-9V@bj8yhf1.ch3.sourceforge.com>

Revision: 5332
          http://opensips.svn.sourceforge.net/opensips/?rev=5332&view=rev
Author:   saguti
Date:     2009-02-18 14:32:57 +0000 (Wed, 18 Feb 2009)

Log Message:
-----------
- Makes detection of pcre library portable, and adds additional locations through LOCALBASE when autodetection fails.

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


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


From saguti at gmail.com  Wed Feb 18 15:34:57 2009
From: saguti at gmail.com (Sergio Gutierrez)
Date: Wed, 18 Feb 2009 09:34:57 -0500
Subject: [OpenSIPS-Devel] Is it possible to commit new "regex" module
	before 1.5?
In-Reply-To: <cc1f582e0902180232y5d49f41eu84cab63c5d84275@mail.gmail.com>
References: <200902170041.29072.ibc@aliax.net>
	<499AB33F.2050606@voice-system.ro>
	<200902180715.05677.dan@ag-projects.com>
	<cc1f582e0902180044v2ddb3106u343b275d1985c76@mail.gmail.com>
	<499BD965.80601@voice-system.ro>
	<cc1f582e0902180226l1d13734btb91c5abcd8aead42@mail.gmail.com>
	<cc1f582e0902180232y5d49f41eu84cab63c5d84275@mail.gmail.com>
Message-ID: <8a4af3e20902180634l7666f00dmb812f33df2b2f120@mail.gmail.com>

Hi I?aki.

I added autodetection of PCRE library and additional locations for searching
the library, to make module more portable, to systems as Solaris.

I apologize for doing it before consulting you, but I did not want to come
without a result! :-)

Regards.

Sergio.

On Wed, Feb 18, 2009 at 5:32 AM, I?aki Baz Castillo <ibc at aliax.net> wrote:

> 2009/2/18 I?aki Baz Castillo <ibc at aliax.net>:
> > Already commited. I just forgot to set:
> >  svn propset svn:keywords "Author Date Id Revision"
> > in some files.
> >
> > I've already added it in my local repository but I don't know how to
> > submit those changes. Must I modify the files?
>
> Ok, when doing a "svn co" the keywords "Date", "Author" and so are
> correctly filled, so it's ok now. I expect that "svn ci" after "svn
> propset svn:keywords "Author Date Id Revision" FILE" did work.
>
> Regards.
>
>
> --
> I?aki Baz Castillo
> <ibc at aliax.net>
>
> _______________________________________________
> Devel mailing list
> Devel at lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
>



-- 
Sergio Guti?rrez
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.opensips.org/pipermail/devel/attachments/20090218/7be5bd53/attachment.htm 

From ibc at aliax.net  Wed Feb 18 15:39:59 2009
From: ibc at aliax.net (=?UTF-8?Q?I=C3=B1aki_Baz_Castillo?=)
Date: Wed, 18 Feb 2009 15:39:59 +0100
Subject: [OpenSIPS-Devel] Is it possible to commit new "regex" module
	before 1.5?
In-Reply-To: <8a4af3e20902180634l7666f00dmb812f33df2b2f120@mail.gmail.com>
References: <200902170041.29072.ibc@aliax.net>
	<499AB33F.2050606@voice-system.ro>
	<200902180715.05677.dan@ag-projects.com>
	<cc1f582e0902180044v2ddb3106u343b275d1985c76@mail.gmail.com>
	<499BD965.80601@voice-system.ro>
	<cc1f582e0902180226l1d13734btb91c5abcd8aead42@mail.gmail.com>
	<cc1f582e0902180232y5d49f41eu84cab63c5d84275@mail.gmail.com>
	<8a4af3e20902180634l7666f00dmb812f33df2b2f120@mail.gmail.com>
Message-ID: <cc1f582e0902180639l487efac4y5763c1991739ce8f@mail.gmail.com>

2009/2/18 Sergio Gutierrez <saguti at gmail.com>:
>
> Hi I?aki.
>
> I added autodetection of PCRE library and additional locations for searching
> the library, to make module more portable, to systems as Solaris.
>
> I apologize for doing it before consulting you, but I did not want to come
> without a result! :-)

It's ok, thanks a lot.

-- 
I?aki Baz Castillo
<ibc at aliax.net>


From anca at opensips.org  Wed Feb 18 16:14:27 2009
From: anca at opensips.org (Anca Vamanu)
Date: Wed, 18 Feb 2009 15:14:27 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[5333]
	trunk/modules/rls/resource_notify.c
Message-ID: <E1LZo83-0007lh-Kh@bj8yhf1.ch3.sourceforge.com>

Revision: 5333
          http://opensips.svn.sourceforge.net/opensips/?rev=5333&view=rev
Author:   anca_vamanu
Date:     2009-02-18 15:14:27 +0000 (Wed, 18 Feb 2009)

Log Message:
-----------
- fixed bug- not sending all update Notifies when state changed 
- reported by Rmnathan in bug #2591935

Modified Paths:
--------------
    trunk/modules/rls/resource_notify.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 Feb 18 16:16:08 2009
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 18 Feb 2009 15:16:08 +0000
Subject: [OpenSIPS-Devel] [ opensips-Bugs-2591935 ] Error in sending NOTIFY
	for PUBLISH in RLS mode
Message-ID: <E1LZo9g-0000yt-5z@d55xhf1.ch3.sourceforge.com>

Bugs item #2591935, was opened at 2009-02-12 08:31
Message generated for change (Comment added) made by anca_vamanu
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=2591935&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: Nathan (rmnathan)
Assigned to: Anca Vamanu (anca_vamanu)
Summary: Error in sending NOTIFY for PUBLISH in RLS mode

Initial Comment:
Hi
When opensips got publish for the user(say E1_1) which has in two list subscriptions, it is sending notify to one user only.
For example:
UE2_1 list will have 2 entry uri like E1_1,E1_2
UE2_2 list will have 2 entry uri like E1_2,E1_1

S2_1 subscribe to UE2_1
S2_2 subscribe to UE2_2
If E1_1 send publish, opensips sends notify to S2_1 only. But it should send notify to S2_2 too.

Please find the attached pcap file for detailed call flow.

Regards,
rmnathan


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

>Comment By: Anca Vamanu (anca_vamanu)
Date: 2009-02-18 17:16

Message:
Hi Rmnathan,

Thank you for this report.
Indeed, you were right- not all update Notifies were sent due to a bug in
the code. I have fixed it. Please update to the new svn version and test it
yourself. I will wait for your feedback before closing this bug report.

regards,
Anca



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

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


From bogdan at voice-system.ro  Wed Feb 18 16:16:12 2009
From: bogdan at voice-system.ro (Bogdan-Andrei Iancu)
Date: Wed, 18 Feb 2009 15:16:12 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[5334] trunk/Makefile
Message-ID: <E1LZo9k-0007np-HX@bj8yhf1.ch3.sourceforge.com>

Revision: 5334
          http://opensips.svn.sourceforge.net/opensips/?rev=5334&view=rev
Author:   bogdan_iancu
Date:     2009-02-18 15:16:12 +0000 (Wed, 18 Feb 2009)

Log Message:
-----------
- new REGEX module is not be default compiled as it depends on the PCRE lib 

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


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


From noreply at sourceforge.net  Wed Feb 18 16:17:00 2009
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 18 Feb 2009 15:17:00 +0000
Subject: [OpenSIPS-Devel] [ opensips-Bugs-2591935 ] Error in sending NOTIFY
	for PUBLISH in RLS mode
Message-ID: <E1LZoAW-00053R-OU@665xhf1.ch3.sourceforge.com>

Bugs item #2591935, was opened at 2009-02-12 08:31
Message generated for change (Comment added) made by anca_vamanu
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=2591935&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: Nathan (rmnathan)
Assigned to: Anca Vamanu (anca_vamanu)
Summary: Error in sending NOTIFY for PUBLISH in RLS mode

Initial Comment:
Hi
When opensips got publish for the user(say E1_1) which has in two list subscriptions, it is sending notify to one user only.
For example:
UE2_1 list will have 2 entry uri like E1_1,E1_2
UE2_2 list will have 2 entry uri like E1_2,E1_1

S2_1 subscribe to UE2_1
S2_2 subscribe to UE2_2
If E1_1 send publish, opensips sends notify to S2_1 only. But it should send notify to S2_2 too.

Please find the attached pcap file for detailed call flow.

Regards,
rmnathan


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

>Comment By: Anca Vamanu (anca_vamanu)
Date: 2009-02-18 17:17

Message:
Hi Rmnathan,

Thank you for this report.
Indeed, you were right- not all update Notifies were sent due to a bug in
the code. I have fixed it. Please update to the new svn version and test it
yourself. I will wait for your feedback before closing this bug report.

regards,
Anca



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

Comment By: Anca Vamanu (anca_vamanu)
Date: 2009-02-18 17:16

Message:
Hi Rmnathan,

Thank you for this report.
Indeed, you were right- not all update Notifies were sent due to a bug in
the code. I have fixed it. Please update to the new svn version and test it
yourself. I will wait for your feedback before closing this bug report.

regards,
Anca



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

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


From noreply at sourceforge.net  Wed Feb 18 16:17:22 2009
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 18 Feb 2009 15:17:22 +0000
Subject: [OpenSIPS-Devel] [ opensips-Bugs-2591935 ] Error in sending NOTIFY
	for PUBLISH in RLS mode
Message-ID: <E1LZoAs-00058Y-Me@h45xhf1.ch3.sourceforge.com>

Bugs item #2591935, was opened at 2009-02-12 08:31
Message generated for change (Comment added) made by anca_vamanu
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=2591935&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: Nathan (rmnathan)
Assigned to: Anca Vamanu (anca_vamanu)
Summary: Error in sending NOTIFY for PUBLISH in RLS mode

Initial Comment:
Hi
When opensips got publish for the user(say E1_1) which has in two list subscriptions, it is sending notify to one user only.
For example:
UE2_1 list will have 2 entry uri like E1_1,E1_2
UE2_2 list will have 2 entry uri like E1_2,E1_1

S2_1 subscribe to UE2_1
S2_2 subscribe to UE2_2
If E1_1 send publish, opensips sends notify to S2_1 only. But it should send notify to S2_2 too.

Please find the attached pcap file for detailed call flow.

Regards,
rmnathan


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

>Comment By: Anca Vamanu (anca_vamanu)
Date: 2009-02-18 17:17

Message:
Hi Rmnathan,

Thank you for this report.
Indeed, you were right- not all update Notifies were sent due to a bug in
the code. I have fixed it. Please update to the new svn version and test it
yourself. I will wait for your feedback before closing this bug report.

regards,
Anca



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

Comment By: Anca Vamanu (anca_vamanu)
Date: 2009-02-18 17:17

Message:
Hi Rmnathan,

Thank you for this report.
Indeed, you were right- not all update Notifies were sent due to a bug in
the code. I have fixed it. Please update to the new svn version and test it
yourself. I will wait for your feedback before closing this bug report.

regards,
Anca



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

Comment By: Anca Vamanu (anca_vamanu)
Date: 2009-02-18 17:16

Message:
Hi Rmnathan,

Thank you for this report.
Indeed, you were right- not all update Notifies were sent due to a bug in
the code. I have fixed it. Please update to the new svn version and test it
yourself. I will wait for your feedback before closing this bug report.

regards,
Anca



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

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


From noreply at sourceforge.net  Wed Feb 18 16:39:47 2009
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 18 Feb 2009 15:39:47 +0000
Subject: [OpenSIPS-Devel] [ opensips-Bugs-2609529 ] Segmentation fault
	related to 'pua' module
Message-ID: <E1LZoWZ-0005RN-SZ@665xhf1.ch3.sourceforge.com>

Bugs item #2609529, was opened at 2009-02-17 18:35
Message generated for change (Comment added) made by anca_vamanu
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=2609529&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: I?aki Baz (ibc_sf)
>Assigned to: Anca Vamanu (anca_vamanu)
Summary: Segmentation fault related to 'pua' module

Initial Comment:
OpenSIPS rev 5323.

This OpenSIPS acts as a proxy for presence messages which are routed to an OpenSIPS presence server running in a different port.


syslog:
---------------
/usr/sbin/opensips[20978]: DBG:core:parse_msg:  version: <SIP/2.
/usr/sbin/opensips[20978]: DBG:core:parse_msg:  status:  <489>
/usr/sbin/opensips[20978]: DBG:core:parse_msg:  reason:  <Bad Ev
/usr/sbin/opensips[20978]: DBG:core:parse_headers: flags=2
/usr/sbin/opensips[20978]: DBG:core:parse_via_param: found param
/usr/sbin/opensips[20978]: DBG:core:parse_via: end of header rea
/usr/sbin/opensips[20978]: DBG:core:parse_headers: via found, fl
/usr/sbin/opensips[20978]: DBG:core:parse_headers: this is the f
/usr/sbin/opensips[20978]: DBG:core:receive_msg: After parse_msg
/usr/sbin/opensips[20978]: DBG:core:forward_reply: found module 
/usr/sbin/opensips[20978]: DBG:core:parse_headers: flags=4
/usr/sbin/opensips[20978]: DBG:core:parse_via_param: found param
/usr/sbin/opensips[20978]: DBG:core:parse_via_param: found param
/usr/sbin/opensips[20978]: DBG:core:parse_via_param: found param
/usr/sbin/opensips[20978]: DBG:core:parse_via: end of header rea
/usr/sbin/opensips[20978]: DBG:core:parse_headers: via found, fl
/usr/sbin/opensips[20978]: DBG:core:parse_headers: parse_headers
/usr/sbin/opensips[20978]: DBG:core:forward_reply: found module 
/usr/sbin/opensips[20978]: DBG:tm:t_check: start=0xfffffffffffff
/usr/sbin/opensips[20978]: DBG:core:parse_headers: flags=22
/usr/sbin/opensips[20978]: DBG:core:parse_to_param: tag=82e3ea5b
/usr/sbin/opensips[20978]: DBG:core:parse_to: end of header reac
/usr/sbin/opensips[20978]: DBG:core:parse_to: display={}, ruri={
/usr/sbin/opensips[20978]: DBG:core:get_hdr_field: <To> [63]; ur
/usr/sbin/opensips[20978]: DBG:core:get_hdr_field: to body [<sip
/usr/sbin/opensips[20978]: DBG:core:get_hdr_field: cseq <CSeq>: 
/usr/sbin/opensips[20978]: DBG:tm:t_reply_matching: hash 65085 l
/usr/sbin/opensips[20978]: DBG:tm:t_reply_matching: REF_UNSAFE: 
/usr/sbin/opensips[20978]: DBG:tm:t_reply_matching: reply matche
/usr/sbin/opensips[20978]: DBG:tm:run_trans_callbacks: trans=0x2
/usr/sbin/opensips[20978]: DBG:tm:t_check: end=0x2b936cb4ff10
/usr/sbin/opensips[20978]: DBG:tm:reply_received: org. status ua
/usr/sbin/opensips[20978]:  ## onreply_route[ON_REPLY_DEFAULT]
/usr/sbin/opensips[20978]: DBG:core:tr_eval_string: i=11 j=8
/usr/sbin/opensips[20978]: DBG:core:parse_headers: flags=8000000
/usr/sbin/opensips[20978]: DBG:core:get_hdr_field: content_lengt
/usr/sbin/opensips[20978]: DBG:core:get_hdr_field: found end of 
/usr/sbin/opensips[20978]: DBG:core:pv_get_useragent: no User-Ag
/usr/sbin/opensips[20978]: 15:43:27 - Reply from 99.131.79.216:5
/usr/sbin/opensips[20978]: 489 (SUBSCRIBE): Bad Event
/usr/sbin/opensips[20978]: DBG:tm:t_should_relay_response: T_cod
/usr/sbin/opensips[20978]: DBG:tm:t_pick_branch: picked branch 0
/usr/sbin/opensips[20978]: DBG:tm:is_3263_failure: dns-failover 
/usr/sbin/opensips[20978]: DBG:tm:relay_reply: branch=0, save=0,
/usr/sbin/opensips[20978]: DBG:core:build_res_buf_from_sip_res: 
/usr/sbin/opensips[20978]: DBG:core:build_res_buf_from_sip_res: 
/usr/sbin/opensips[20978]: DBG:core:_shm_resize: resize(0) calle
/usr/sbin/opensips[20978]: DBG:tm:insert_timer_unsafe: [2]: 0x2b
/usr/sbin/opensips[20978]: DBG:tm:relay_reply: sent buf=0x6b7920
/usr/sbin/opensips[20978]: DBG:tm:cleanup_uac_timers: RETR/FR ti
/usr/sbin/opensips[20978]: DBG:tm:t_unref: UNREF_UNSAFE: after i
/usr/sbin/opensips[20978]: DBG:core:destroy_avp_list: destroying
/usr/sbin/opensips[20978]: DBG:core:receive_msg: cleaning up
/usr/sbin/opensips[20934]: DBG:core:tcp_send: buf= SUBSCRIBE sip
/usr/sbin/opensips[20934]: DBG:tm:set_timer: relative timeout is
/usr/sbin/opensips[20934]: DBG:tm:insert_timer_unsafe: [0]: 0x2b
/usr/sbin/opensips[20934]: DBG:tm:t_relay_to: new transaction fw
/usr/sbin/opensips[20934]: DBG:tm:t_unref: UNREF_UNSAFE: after i
/usr/sbin/opensips[20934]: DBG:core:destroy_avp_list: destroying
/usr/sbin/opensips[20934]: DBG:core:receive_msg: cleaning up
/usr/sbin/opensips[20994]: CRITICAL:core:receive_fd: EOF on 46
---------------



coredump:
---------------
Core was generated by `/usr/sbin/opensips -P /var/run/opensips/opensips.pid -m 128 -u opensips -g open'.
Program terminated with signal 11, Segmentation fault.
#0  0x00002b936a901d78 in publ_build_hdr () from /usr/lib/opensips/modules/pua.so
(gdb) bt
#0  0x00002b936a901d78 in publ_build_hdr () from /usr/lib/opensips/modules/pua.so
#1  0x00002b936a8fee4c in bind_pua () from /usr/lib/opensips/modules/pua.so
#2  0x000000000046960c in start_timer_processes ()
#3  0x0000000000423661 in main ()
---------------

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

>Comment By: Anca Vamanu (anca_vamanu)
Date: 2009-02-18 17:39

Message:
Hi Inaki,

Neither the gdb back trace nor the log offer much information. Can you try
to copy the core in the directory where you have the sources and run from
there: 'gdb opensips core'. If still there are no line numbers - run
'ulimit -c unlimited' delete the old core and run the opensips again with
the same usage case to get a new core.
Please print here the output of the gdb back trace with 'bt full'.

regards,
Anca

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

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


From osas at voipembedded.com  Wed Feb 18 17:03:19 2009
From: osas at voipembedded.com (Ovidiu Sas)
Date: Wed, 18 Feb 2009 16:03:19 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[5335]
	trunk/modules/load_balancer/
Message-ID: <E1LZotL-0003TU-I8@d5vjzd1.ch3.sourceforge.com>

Revision: 5335
          http://opensips.svn.sourceforge.net/opensips/?rev=5335&view=rev
Author:   osas
Date:     2009-02-18 16:03:19 +0000 (Wed, 18 Feb 2009)

Log Message:
-----------
set svn ignore props

Property Changed:
----------------
    trunk/modules/load_balancer/


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


From noreply at sourceforge.net  Wed Feb 18 17:10:41 2009
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 18 Feb 2009 16:10:41 +0000
Subject: [OpenSIPS-Devel] [ opensips-Bugs-2538399 ] Bug in presence when
	using fallback2db
Message-ID: <E1LZp0T-0006zV-G6@d45xhf1.ch3.sourceforge.com>

Bugs item #2538399, was opened at 2009-01-26 21:39
Message generated for change (Comment added) made by anca_vamanu
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=2538399&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: Oren K (oren_k)
Assigned to: Anca Vamanu (anca_vamanu)
Summary: Bug in presence when using fallback2db

Initial Comment:
Hi,

While using the presence module, I run this scenario:

a. user1 SUBSCRIBE's to presence of user2
(subscription is now pending)

b. user2 allows user1 in pres-rules
(refreshWatchers is called, subscription is now active. user1 receives a NOTIFY from presence server with user2's current tuple and Subscription-State: active)

c. user2 PUBLISH'es a new presence tuple
-- at this point presence server should NOTIFY user1 of the new presence but it doesn't (that's the bug).


My modparams:

modparam("presence|presence_xml", "db_url", "mysql://root at localhost/opensips")

modparam("presence", "server_address", "sip:presence.example.com:10500")

modparam("presence", "fallback2db", 1)
modparam("presence", "clean_period", 30)


What I see in the debug trace is that get_subs_dialog (from notify.c) can't find any dialogs in the database, and all those in the subs hash are flagged NO_UPDATEDB_FLAG. This is probably what's causing the problem. 
Strangely, in the above scenario if user1 un-SUBSCRIBEs and re-SUBSCRIBEs to user2's presence - it does receive notifications.

Regards,
Oren K.

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

>Comment By: Anca Vamanu (anca_vamanu)
Date: 2009-02-18 18:10

Message:
Hi, 

I have just now made some changes in presence module for fallback2db case.
Can you please update to the newest svn version for 1.5 and test again?

regards,
Anca

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

Comment By: Oren K (oren_k)
Date: 2009-02-07 02:23

Message:
Hi Anca,

I've attached a debug-log and wireshark pcap file to the post. The pcap
file also contains the XCAP PUTs to change the presence rules. The only
error in the log comes from presence_xml not being able to extract a tuple
node because our client uses <pdm:person> for the presence (Same bug
happened to us when we tried with <tuple> so that's not the issue). The
things that strike me odd in presence_bug.log are:

(after step b. user2 allows user1 in pres-rules)
line 634: DBG:presence:update_pw_dialogs: found 1 matching dialogs

the module finds the watcher dialog and updates it due to refreshWatchers.
user1 receives a NOTIFY with Subscription-State:active. Now step c. user2
PUBLISH'es a new presence tuple:

line 919: DBG:core:parse_msg:  method:  <PUBLISH>

everything looks okay BUT:

line 1087: DBG:presence:get_subs_db: The query for subscribtion for [uri]=
sip:user2 at openims.summit-tech.ca for [event]= presence returned no result
line 1110: DBG:presence:get_subs_dialog: s->db_flag== UPDATEDB_FLAG
line 1111: DBG:presence:get_subs_dialog: found 0 dialogs( 0 in database
and 0 in hash_table)
line 1112: DBG:presence:publ_notify: Could not find subs_dialog

..suddenly there are no subscribers?

Thanks.


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

Comment By: Anca Vamanu (anca_vamanu)
Date: 2009-02-06 20:14

Message:
Hi Oren,

I have just downloaded myself the release and tested and the scenario that
you described works. 
Do you notice any error in your log file?

regards,
Anca

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

Comment By: Oren K (oren_k)
Date: 2009-02-01 18:41

Message:
Sorry I forgot to login, that comment is from me :)

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

Comment By: Nobody/Anonymous (nobody)
Date: 2009-01-28 17:12

Message:
Thanks for the reply anca. Version is opensips-1.4.4-tls, compiled from the
sources with TLS="1". 

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

Comment By: Anca Vamanu (anca_vamanu)
Date: 2009-01-28 13:48

Message:
Hi Oren,

What OpenSIPS version are you using? Trunk or stable release?

regards,
Anca

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

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


From noreply at sourceforge.net  Wed Feb 18 17:11:53 2009
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 18 Feb 2009 16:11:53 +0000
Subject: [OpenSIPS-Devel] [ opensips-Bugs-2538399 ] Bug in presence when
	using fallback2db
Message-ID: <E1LZp1d-0006L2-3H@h45xhf1.ch3.sourceforge.com>

Bugs item #2538399, was opened at 2009-01-26 21:39
Message generated for change (Comment added) made by anca_vamanu
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=2538399&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: Oren K (oren_k)
Assigned to: Anca Vamanu (anca_vamanu)
Summary: Bug in presence when using fallback2db

Initial Comment:
Hi,

While using the presence module, I run this scenario:

a. user1 SUBSCRIBE's to presence of user2
(subscription is now pending)

b. user2 allows user1 in pres-rules
(refreshWatchers is called, subscription is now active. user1 receives a NOTIFY from presence server with user2's current tuple and Subscription-State: active)

c. user2 PUBLISH'es a new presence tuple
-- at this point presence server should NOTIFY user1 of the new presence but it doesn't (that's the bug).


My modparams:

modparam("presence|presence_xml", "db_url", "mysql://root at localhost/opensips")

modparam("presence", "server_address", "sip:presence.example.com:10500")

modparam("presence", "fallback2db", 1)
modparam("presence", "clean_period", 30)


What I see in the debug trace is that get_subs_dialog (from notify.c) can't find any dialogs in the database, and all those in the subs hash are flagged NO_UPDATEDB_FLAG. This is probably what's causing the problem. 
Strangely, in the above scenario if user1 un-SUBSCRIBEs and re-SUBSCRIBEs to user2's presence - it does receive notifications.

Regards,
Oren K.

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

>Comment By: Anca Vamanu (anca_vamanu)
Date: 2009-02-18 18:11

Message:
Hi, 

I have just now made some changes in presence module for fallback2db case.
Can you please update to the newest svn version for 1.5 and test again?

regards,
Anca

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

Comment By: Anca Vamanu (anca_vamanu)
Date: 2009-02-18 18:10

Message:
Hi, 

I have just now made some changes in presence module for fallback2db case.
Can you please update to the newest svn version for 1.5 and test again?

regards,
Anca

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

Comment By: Oren K (oren_k)
Date: 2009-02-07 02:23

Message:
Hi Anca,

I've attached a debug-log and wireshark pcap file to the post. The pcap
file also contains the XCAP PUTs to change the presence rules. The only
error in the log comes from presence_xml not being able to extract a tuple
node because our client uses <pdm:person> for the presence (Same bug
happened to us when we tried with <tuple> so that's not the issue). The
things that strike me odd in presence_bug.log are:

(after step b. user2 allows user1 in pres-rules)
line 634: DBG:presence:update_pw_dialogs: found 1 matching dialogs

the module finds the watcher dialog and updates it due to refreshWatchers.
user1 receives a NOTIFY with Subscription-State:active. Now step c. user2
PUBLISH'es a new presence tuple:

line 919: DBG:core:parse_msg:  method:  <PUBLISH>

everything looks okay BUT:

line 1087: DBG:presence:get_subs_db: The query for subscribtion for [uri]=
sip:user2 at openims.summit-tech.ca for [event]= presence returned no result
line 1110: DBG:presence:get_subs_dialog: s->db_flag== UPDATEDB_FLAG
line 1111: DBG:presence:get_subs_dialog: found 0 dialogs( 0 in database
and 0 in hash_table)
line 1112: DBG:presence:publ_notify: Could not find subs_dialog

..suddenly there are no subscribers?

Thanks.


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

Comment By: Anca Vamanu (anca_vamanu)
Date: 2009-02-06 20:14

Message:
Hi Oren,

I have just downloaded myself the release and tested and the scenario that
you described works. 
Do you notice any error in your log file?

regards,
Anca

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

Comment By: Oren K (oren_k)
Date: 2009-02-01 18:41

Message:
Sorry I forgot to login, that comment is from me :)

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

Comment By: Nobody/Anonymous (nobody)
Date: 2009-01-28 17:12

Message:
Thanks for the reply anca. Version is opensips-1.4.4-tls, compiled from the
sources with TLS="1". 

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

Comment By: Anca Vamanu (anca_vamanu)
Date: 2009-01-28 13:48

Message:
Hi Oren,

What OpenSIPS version are you using? Trunk or stable release?

regards,
Anca

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

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


From bogdan at voice-system.ro  Wed Feb 18 18:30:27 2009
From: bogdan at voice-system.ro (Bogdan-Andrei Iancu)
Date: Wed, 18 Feb 2009 17:30:27 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[5336] trunk/modules/dialog
Message-ID: <E1LZqFf-0002hF-AW@c3vjzd1.ch3.sourceforge.com>

Revision: 5336
          http://opensips.svn.sourceforge.net/opensips/?rev=5336&view=rev
Author:   bogdan_iancu
Date:     2009-02-18 17:30:27 +0000 (Wed, 18 Feb 2009)

Log Message:
-----------
- docs updated

Modified Paths:
--------------
    trunk/modules/dialog/README
    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  Wed Feb 18 18:34:47 2009
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 18 Feb 2009 17:34:47 +0000
Subject: [OpenSIPS-Devel] [ opensips-Bugs-2609529 ] Segmentation fault
	related to 'pua' module
Message-ID: <E1LZqJr-0006XD-IY@b55xhf1.ch3.sourceforge.com>

Bugs item #2609529, was opened at 2009-02-17 17:35
Message generated for change (Comment added) made by ibc_sf
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=2609529&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: I?aki Baz (ibc_sf)
Assigned to: Anca Vamanu (anca_vamanu)
Summary: Segmentation fault related to 'pua' module

Initial Comment:
OpenSIPS rev 5323.

This OpenSIPS acts as a proxy for presence messages which are routed to an OpenSIPS presence server running in a different port.


syslog:
---------------
/usr/sbin/opensips[20978]: DBG:core:parse_msg:  version: <SIP/2.
/usr/sbin/opensips[20978]: DBG:core:parse_msg:  status:  <489>
/usr/sbin/opensips[20978]: DBG:core:parse_msg:  reason:  <Bad Ev
/usr/sbin/opensips[20978]: DBG:core:parse_headers: flags=2
/usr/sbin/opensips[20978]: DBG:core:parse_via_param: found param
/usr/sbin/opensips[20978]: DBG:core:parse_via: end of header rea
/usr/sbin/opensips[20978]: DBG:core:parse_headers: via found, fl
/usr/sbin/opensips[20978]: DBG:core:parse_headers: this is the f
/usr/sbin/opensips[20978]: DBG:core:receive_msg: After parse_msg
/usr/sbin/opensips[20978]: DBG:core:forward_reply: found module 
/usr/sbin/opensips[20978]: DBG:core:parse_headers: flags=4
/usr/sbin/opensips[20978]: DBG:core:parse_via_param: found param
/usr/sbin/opensips[20978]: DBG:core:parse_via_param: found param
/usr/sbin/opensips[20978]: DBG:core:parse_via_param: found param
/usr/sbin/opensips[20978]: DBG:core:parse_via: end of header rea
/usr/sbin/opensips[20978]: DBG:core:parse_headers: via found, fl
/usr/sbin/opensips[20978]: DBG:core:parse_headers: parse_headers
/usr/sbin/opensips[20978]: DBG:core:forward_reply: found module 
/usr/sbin/opensips[20978]: DBG:tm:t_check: start=0xfffffffffffff
/usr/sbin/opensips[20978]: DBG:core:parse_headers: flags=22
/usr/sbin/opensips[20978]: DBG:core:parse_to_param: tag=82e3ea5b
/usr/sbin/opensips[20978]: DBG:core:parse_to: end of header reac
/usr/sbin/opensips[20978]: DBG:core:parse_to: display={}, ruri={
/usr/sbin/opensips[20978]: DBG:core:get_hdr_field: <To> [63]; ur
/usr/sbin/opensips[20978]: DBG:core:get_hdr_field: to body [<sip
/usr/sbin/opensips[20978]: DBG:core:get_hdr_field: cseq <CSeq>: 
/usr/sbin/opensips[20978]: DBG:tm:t_reply_matching: hash 65085 l
/usr/sbin/opensips[20978]: DBG:tm:t_reply_matching: REF_UNSAFE: 
/usr/sbin/opensips[20978]: DBG:tm:t_reply_matching: reply matche
/usr/sbin/opensips[20978]: DBG:tm:run_trans_callbacks: trans=0x2
/usr/sbin/opensips[20978]: DBG:tm:t_check: end=0x2b936cb4ff10
/usr/sbin/opensips[20978]: DBG:tm:reply_received: org. status ua
/usr/sbin/opensips[20978]:  ## onreply_route[ON_REPLY_DEFAULT]
/usr/sbin/opensips[20978]: DBG:core:tr_eval_string: i=11 j=8
/usr/sbin/opensips[20978]: DBG:core:parse_headers: flags=8000000
/usr/sbin/opensips[20978]: DBG:core:get_hdr_field: content_lengt
/usr/sbin/opensips[20978]: DBG:core:get_hdr_field: found end of 
/usr/sbin/opensips[20978]: DBG:core:pv_get_useragent: no User-Ag
/usr/sbin/opensips[20978]: 15:43:27 - Reply from 99.131.79.216:5
/usr/sbin/opensips[20978]: 489 (SUBSCRIBE): Bad Event
/usr/sbin/opensips[20978]: DBG:tm:t_should_relay_response: T_cod
/usr/sbin/opensips[20978]: DBG:tm:t_pick_branch: picked branch 0
/usr/sbin/opensips[20978]: DBG:tm:is_3263_failure: dns-failover 
/usr/sbin/opensips[20978]: DBG:tm:relay_reply: branch=0, save=0,
/usr/sbin/opensips[20978]: DBG:core:build_res_buf_from_sip_res: 
/usr/sbin/opensips[20978]: DBG:core:build_res_buf_from_sip_res: 
/usr/sbin/opensips[20978]: DBG:core:_shm_resize: resize(0) calle
/usr/sbin/opensips[20978]: DBG:tm:insert_timer_unsafe: [2]: 0x2b
/usr/sbin/opensips[20978]: DBG:tm:relay_reply: sent buf=0x6b7920
/usr/sbin/opensips[20978]: DBG:tm:cleanup_uac_timers: RETR/FR ti
/usr/sbin/opensips[20978]: DBG:tm:t_unref: UNREF_UNSAFE: after i
/usr/sbin/opensips[20978]: DBG:core:destroy_avp_list: destroying
/usr/sbin/opensips[20978]: DBG:core:receive_msg: cleaning up
/usr/sbin/opensips[20934]: DBG:core:tcp_send: buf= SUBSCRIBE sip
/usr/sbin/opensips[20934]: DBG:tm:set_timer: relative timeout is
/usr/sbin/opensips[20934]: DBG:tm:insert_timer_unsafe: [0]: 0x2b
/usr/sbin/opensips[20934]: DBG:tm:t_relay_to: new transaction fw
/usr/sbin/opensips[20934]: DBG:tm:t_unref: UNREF_UNSAFE: after i
/usr/sbin/opensips[20934]: DBG:core:destroy_avp_list: destroying
/usr/sbin/opensips[20934]: DBG:core:receive_msg: cleaning up
/usr/sbin/opensips[20994]: CRITICAL:core:receive_fd: EOF on 46
---------------



coredump:
---------------
Core was generated by `/usr/sbin/opensips -P /var/run/opensips/opensips.pid -m 128 -u opensips -g open'.
Program terminated with signal 11, Segmentation fault.
#0  0x00002b936a901d78 in publ_build_hdr () from /usr/lib/opensips/modules/pua.so
(gdb) bt
#0  0x00002b936a901d78 in publ_build_hdr () from /usr/lib/opensips/modules/pua.so
#1  0x00002b936a8fee4c in bind_pua () from /usr/lib/opensips/modules/pua.so
#2  0x000000000046960c in start_timer_processes ()
#3  0x0000000000423661 in main ()
---------------

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

>Comment By: I?aki Baz (ibc_sf)
Date: 2009-02-18 18:34

Message:
Ok, I'll do that.
BTW my OpenSIPS proxy has crashed now with this backtrace:

------------
#0  0x00002b6c934ffa92 in mysql_stmt_result_metadata () from
/usr/lib/libmysqlclient.so.15
#1  0x00002b6c9338a1de in db_mysql_free_result () from
/usr/lib/opensips/modules/db_mysql.so
#2  0x00002b6c9338b156 in db_mysql_query () from
/usr/lib/opensips/modules/db_mysql.so
#3  0x00002b6c946258f8 in ?? () from /usr/lib/opensips/modules/auth_db.so
#4  0x000000000040f894 in do_action ()
#5  0x000000000040e0f3 in run_action_list ()
#6  0x000000000044c957 in eval_expr ()
#7  0x000000000044c3d0 in eval_expr ()
#8  0x000000000040f939 in do_action ()
#9  0x000000000040e0f3 in run_action_list ()
#10 0x000000000041093a in do_action ()
#11 0x000000000040e0f3 in run_action_list ()
#12 0x000000000041176f in do_action ()
#13 0x000000000040e0f3 in run_action_list ()
#14 0x000000000041176f in do_action ()
#15 0x000000000040e0f3 in run_action_list ()
#16 0x000000000040e480 in run_top_route ()
#17 0x0000000000441b4c in receive_msg ()
#18 0x0000000000464bfd in tcp_read_req ()
#19 0x000000000046691e in tcp_read_req ()
#20 0x0000000000468114 in tcp_receive_loop ()
#21 0x000000000045b83d in tcp_init_children ()
#22 0x000000000042368e in main ()
------------

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

Comment By: Anca Vamanu (anca_vamanu)
Date: 2009-02-18 16:39

Message:
Hi Inaki,

Neither the gdb back trace nor the log offer much information. Can you try
to copy the core in the directory where you have the sources and run from
there: 'gdb opensips core'. If still there are no line numbers - run
'ulimit -c unlimited' delete the old core and run the opensips again with
the same usage case to get a new core.
Please print here the output of the gdb back trace with 'bt full'.

regards,
Anca

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

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


From bogdan at voice-system.ro  Wed Feb 18 21:18:10 2009
From: bogdan at voice-system.ro (Bogdan-Andrei Iancu)
Date: Wed, 18 Feb 2009 20:18:10 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[5337]
	trunk/modules/carrierroute
Message-ID: <E1LZsry-0003O8-H8@74yxhf1.ch3.sourceforge.com>

Revision: 5337
          http://opensips.svn.sourceforge.net/opensips/?rev=5337&view=rev
Author:   bogdan_iancu
Date:     2009-02-18 20:18:10 +0000 (Wed, 18 Feb 2009)

Log Message:
-----------
- fixed typo in docs

Modified Paths:
--------------
    trunk/modules/carrierroute/README
    trunk/modules/carrierroute/doc/carrierroute_admin.xml


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


From bogdan at voice-system.ro  Wed Feb 18 21:20:00 2009
From: bogdan at voice-system.ro (Bogdan-Andrei Iancu)
Date: Wed, 18 Feb 2009 20:20:00 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[5338]
	trunk/modules/carrierroute
Message-ID: <E1LZstk-0003Qu-UI@74yxhf1.ch3.sourceforge.com>

Revision: 5338
          http://opensips.svn.sourceforge.net/opensips/?rev=5338&view=rev
Author:   bogdan_iancu
Date:     2009-02-18 20:20:00 +0000 (Wed, 18 Feb 2009)

Log Message:
-----------
one more doc typo fixed

Modified Paths:
--------------
    trunk/modules/carrierroute/README
    trunk/modules/carrierroute/doc/carrierroute_admin.xml


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


From bogdan at voice-system.ro  Wed Feb 18 21:20:20 2009
From: bogdan at voice-system.ro (Bogdan-Andrei Iancu)
Date: Wed, 18 Feb 2009 20:20:20 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[5339]
	branches/1.4/modules/carrierroute
Message-ID: <E1LZsu4-0003Rz-Ny@74yxhf1.ch3.sourceforge.com>

Revision: 5339
          http://opensips.svn.sourceforge.net/opensips/?rev=5339&view=rev
Author:   bogdan_iancu
Date:     2009-02-18 20:20:20 +0000 (Wed, 18 Feb 2009)

Log Message:
-----------
- fixed typo in docs

Modified Paths:
--------------
    branches/1.4/modules/carrierroute/README
    branches/1.4/modules/carrierroute/doc/carrierroute_admin.xml


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


From bogdan at voice-system.ro  Wed Feb 18 22:01:30 2009
From: bogdan at voice-system.ro (Bogdan-Andrei Iancu)
Date: Wed, 18 Feb 2009 21:01:30 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[5340] trunk/modules/db_mysql
Message-ID: <E1LZtXu-0007m6-JF@bj8yhf1.ch3.sourceforge.com>

Revision: 5340
          http://opensips.svn.sourceforge.net/opensips/?rev=5340&view=rev
Author:   bogdan_iancu
Date:     2009-02-18 21:01:30 +0000 (Wed, 18 Feb 2009)

Log Message:
-----------
- fixed re-initialization of prepared statements when the connection to the MYSQL server times out it the MYSQL server is restarted.

Closes 2608188.

Modified Paths:
--------------
    trunk/modules/db_mysql/dbase.c
    trunk/modules/db_mysql/my_con.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 Feb 18 22:02:58 2009
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 18 Feb 2009 21:02:58 +0000
Subject: [OpenSIPS-Devel] [ opensips-Bugs-2608188 ] OpenSIPS latest trunk
	libmysqlclient segfault
Message-ID: <E1LZtZK-0008BY-GB@155xhf1.ch3.sourceforge.com>

Bugs item #2608188, was opened at 2009-02-17 08:02
Message generated for change (Comment added) made by bogdan_iancu
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=2608188&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: 8
Private: No
Submitted By: Om Bikram Thapa (omthapa)
Assigned to: Bogdan-Andrei Iancu (bogdan_iancu)
Summary: OpenSIPS latest trunk libmysqlclient segfault 

Initial Comment:
OpenSIPS latest trunk on Debian Lenny/AMD64 dies with libmysqlclient segfault after a MySQL restart. The event that triggers this crash is registration related database query immediately after a MySQL restart. Once OpenSIPS is restarted after a crash, everything runs fine until next MySQL restart.

The log shows:

"opensips[16769]: segfault at 4c8 ip 7f36728bf283 sp 7fff7ba11a90 error 4 in libmysqlclient.so.15.0.0[7f3672862000+1bf000]"
 
and gdb bt gives following results:

---------------
Program terminated with signal 11, Segmentation fault.
[New process 16769]
#0  0x00007f36728bf283 in mysql_stmt_result_metadata ()
   from /usr/lib/libmysqlclient.so.15
(gdb) bt
#0  0x00007f36728bf283 in mysql_stmt_result_metadata ()
   from /usr/lib/libmysqlclient.so.15
#1  0x00007f3672c707b7 in db_mysql_do_prepared_query (conn=0x78b278, 
    query=<value optimized out>, v=0x7fff7ba11d20, n=1, uv=0x0, un=0)
    at dbase.c:363
#2  0x00007f3672c72e1f in db_mysql_query (_h=0x78b278, 
    _k=<value optimized out>, _op=<value optimized out>, _v=0x7fff7ba11d20, 
    _c=<value optimized out>, _n=1, _nc=2, _o=0x0, _r=0x7fff7ba11dc0)
    at dbase.c:591
#3  0x00007f366f3f0398 in authorize (_m=0x78fe98, 
    _realm=<value optimized out>, _table=<value optimized out>, 
    _hftype=<value optimized out>) at authorize.c:107
#4  0x000000000040f869 in do_action (a=0x780a48, msg=0x78fe98) at action.c:961
#5  0x000000000040e7e5 in run_action_list (a=<value optimized out>, 
    msg=0x78fe98) at action.c:139
#6  0x000000000046f194 in eval_elem (e=0x780b18, msg=0x78fe98, val=0x0)
    at route.c:1189
#7  0x00000000004708ed in eval_expr (e=0x120b1e0, msg=0x78fe98, val=0x0)
    at route.c:1486
#8  0x000000000047089c in eval_expr (e=0x780b60, msg=0x78fe98, val=0x0)
    at route.c:1502
#9  0x00000000004708c5 in eval_expr (e=0x780ba8, msg=0x78fe98, val=0x0)
    at route.c:1507
---Type <return> to continue, or q <return> to quit---
#10 0x000000000040f91c in do_action (a=0x780f40, msg=0x78fe98) at action.c:688
#11 0x000000000040e7e5 in run_action_list (a=<value optimized out>, 
    msg=0x78fe98) at action.c:139
#12 0x00000000004114d3 in do_action (a=0x781eb0, msg=0x78fe98) at action.c:705
#13 0x000000000040e7e5 in run_action_list (a=<value optimized out>, 
    msg=0x78fe98) at action.c:139
#14 0x0000000000410e07 in do_action (a=0x77ee88, msg=0x78fe98) at action.c:119
#15 0x000000000040e7e5 in run_action_list (a=<value optimized out>, 
    msg=0x78fe98) at action.c:139
#16 0x00000000004114d3 in do_action (a=0x77f028, msg=0x78fe98) at action.c:705
#17 0x000000000040e7e5 in run_action_list (a=<value optimized out>, 
    msg=0x78fe98) at action.c:139
#18 0x00000000004125fe in run_top_route (a=0x777e78, msg=0x78fe98)
    at action.c:119
#19 0x000000000045e898 in receive_msg (
    buf=0x749180 "REGISTER sip:x.x.x.x SIP/2.0\r\nCSeq: 2 REGISTER\r\nVia: SIP/2.0/UDP x.x.x.x:5061;branch=z9hG4bK60f1b2dd-57fa-dd11-9401-0015c5404858;rport\r\nUser-Agent: Ekiga/2.0.12\r\nAuthorization: Dige"..., 
    len=749, rcv_info=0x7fff7ba13530) at receive.c:165
#20 0x000000000049d3a6 in udp_rcv_loop () at udp_server.c:449
#21 0x00000000004291fb in main (argc=<value optimized out>, 
    argv=0x7fff7ba13718) at main.c:778
----------------


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

>Comment By: Bogdan-Andrei Iancu (bogdan_iancu)
Date: 2009-02-18 23:02

Message:
Hi Om,

I hopefully fixed the problem - please update from SVN and give it another
try. Let me know if now works.

Thanks and regards,
Bogdan

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

Comment By: Om Bikram Thapa (omthapa)
Date: 2009-02-18 15:11

Message:
I modified domain in opensips domain table, immediately after that the
server crashed upon registration event with log  general protection
ip:7f249016986c sp:7fff992bf320 error:0 in
libmysqlclient.so.15.0.0[7f2490110000+1bf000]" and gdb backtrace now points
to different code:

----------
#0  0x00007f7a4c26f86c in mysql_stmt_fetch () from
/usr/lib/libmysqlclient.so.15
#1  0x00007f7a4c628a48 in db_mysql_convert_result (_h=0x78b278,
_r=0x78ba28) at res.c:161
#2  0x00007f7a4c626aaa in db_mysql_store_result (_h=0x78b278,
_r=0x7fff553c5770) at dbase.c:513
#3  0x00007f7a4c626e39 in db_mysql_query (_h=0x78b278, _k=<value optimized
out>, _op=<value optimized out>, _v=0x7fff553c56d0, _c=<value optimized
out>,
    _n=1, _nc=2, _o=0x0, _r=0x7fff553c5770) at dbase.c:593
#4  0x00007f7a48da4398 in authorize (_m=0x78fe98, _realm=<value optimized
out>, _table=<value optimized out>, _hftype=<value optimized out>)
    at authorize.c:107
#5  0x000000000040f869 in do_action (a=0x780a48, msg=0x78fe98) at
action.c:961
#6  0x000000000040e7e5 in run_action_list (a=<value optimized out>,
msg=0x78fe98) at action.c:139
#7  0x000000000046f194 in eval_elem (e=0x780b18, msg=0x78fe98, val=0x20)
at route.c:1189
#8  0x00000000004708ed in eval_expr (e=0xe543d0, msg=0x78fe98, val=0x0) at
route.c:1486
#9  0x000000000047089c in eval_expr (e=0x780b60, msg=0x78fe98, val=0x0) at
route.c:1502
#10 0x00000000004708c5 in eval_expr (e=0x780ba8, msg=0x78fe98, val=0x0) at
route.c:1507
#11 0x000000000040f91c in do_action (a=0x780f40, msg=0x78fe98) at
action.c:688
#12 0x000000000040e7e5 in run_action_list (a=<value optimized out>,
msg=0x78fe98) at action.c:139
#13 0x00000000004114d3 in do_action (a=0x781eb0, msg=0x78fe98) at
action.c:705
#14 0x000000000040e7e5 in run_action_list (a=<value optimized out>,
msg=0x78fe98) at action.c:139
#15 0x0000000000410e07 in do_action (a=0x77ee88, msg=0x78fe98) at
action.c:119
#16 0x000000000040e7e5 in run_action_list (a=<value optimized out>,
msg=0x78fe98) at action.c:139
#17 0x00000000004114d3 in do_action (a=0x77f028, msg=0x78fe98) at
action.c:705
#18 0x000000000040e7e5 in run_action_list (a=<value optimized out>,
msg=0x78fe98) at action.c:139
#19 0x00000000004125fe in run_top_route (a=0x777e78, msg=0x78fe98) at
action.c:119
#20 0x000000000045e898 in receive_msg (
    buf=0x749180 "REGISTER sip:x.x.x.x;transport=UDP SIP/2.0\r\nVia:
SIP/2.0/UDP
x.x.x.x:5060;branch=z9hG4bKgcjsr9edklicvlhif2tfvub;rport\r\nFrom:
<sip:300000 at x.x."..., len=693, rcv_info=0x7fff553c6ee0) at receive.c:165
#21 0x000000000049d3a6 in udp_rcv_loop () at udp_server.c:449
#22 0x00000000004291fb in main (argc=<value optimized out>,
argv=0x7fff553c70c8) at main.c:778
-----------------

I think this crash is also related to the same issue.

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

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


From ibc at aliax.net  Wed Feb 18 22:54:27 2009
From: ibc at aliax.net (=?utf-8?q?I=C3=B1aki_Baz_Castillo?=)
Date: Wed, 18 Feb 2009 22:54:27 +0100
Subject: [OpenSIPS-Devel] When "make deb-etch" regex module is not compiled
Message-ID: <200902182254.27994.ibc@aliax.net>

Hi, I've upgraded to trunk version and after doing "make deb-etch" regex.so 
doesn't appear in /usr/lib/opensips/modules/.

This is because in debian/rules "regex" is not included in ALL_MODULES. Should 
it be? which is the common behaviour here?

Thanks.

-- 
I?aki Baz Castillo


From saguti at gmail.com  Wed Feb 18 22:58:56 2009
From: saguti at gmail.com (Sergio Gutierrez)
Date: Wed, 18 Feb 2009 16:58:56 -0500
Subject: [OpenSIPS-Devel] When "make deb-etch" regex module is not
	compiled
In-Reply-To: <200902182254.27994.ibc@aliax.net>
References: <200902182254.27994.ibc@aliax.net>
Message-ID: <8a4af3e20902181358w4a3d9a08sb8c44cfcb349c748@mail.gmail.com>

Hi I?aki.

I think it is because regex is not compiled by default because of its
dependency on pcre library.

Regards.

Sergio.

On Wed, Feb 18, 2009 at 4:54 PM, I?aki Baz Castillo <ibc at aliax.net> wrote:

> Hi, I've upgraded to trunk version and after doing "make deb-etch" regex.so
> doesn't appear in /usr/lib/opensips/modules/.
>
> This is because in debian/rules "regex" is not included in ALL_MODULES.
> Should
> it be? which is the common behaviour here?
>
> Thanks.
>
> --
> I?aki Baz Castillo
>
> _______________________________________________
> Devel mailing list
> Devel at lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
>



-- 
Sergio Guti?rrez
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.opensips.org/pipermail/devel/attachments/20090218/50872e1a/attachment-0001.htm 

From ibc at aliax.net  Wed Feb 18 23:09:48 2009
From: ibc at aliax.net (=?utf-8?q?I=C3=B1aki_Baz_Castillo?=)
Date: Wed, 18 Feb 2009 23:09:48 +0100
Subject: [OpenSIPS-Devel] When "make deb-etch" regex module is not
	compiled
In-Reply-To: <8a4af3e20902181358w4a3d9a08sb8c44cfcb349c748@mail.gmail.com>
References: <200902182254.27994.ibc@aliax.net>
	<8a4af3e20902181358w4a3d9a08sb8c44cfcb349c748@mail.gmail.com>
Message-ID: <200902182309.48910.ibc@aliax.net>

El Mi?rcoles, 18 de Febrero de 2009, Sergio Gutierrez escribi?:
> Hi I?aki.
>
> I think it is because regex is not compiled by default because of its
> dependency on pcre library.

Hi Sergio, please chech ALL_MODULES value in debian/rules. All the modules 
appear there, also those requiring external libraries.

The "make deb-*" and normal "make" are very different since "make deb-*" tries 
to compile most of the modules.


-- 
I?aki Baz Castillo


From bogdan at voice-system.ro  Wed Feb 18 23:51:05 2009
From: bogdan at voice-system.ro (Bogdan-Andrei Iancu)
Date: Wed, 18 Feb 2009 22:51:05 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[5341]
	trunk/modules/drouting/drouting.c
Message-ID: <E1LZvFx-00072x-8y@74yxhf1.ch3.sourceforge.com>

Revision: 5341
          http://opensips.svn.sourceforge.net/opensips/?rev=5341&view=rev
Author:   bogdan_iancu
Date:     2009-02-18 22:51:05 +0000 (Wed, 18 Feb 2009)

Log Message:
-----------
-fixed the bogus mem free when using AVP as param for do_routing()

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 voice-system.ro  Thu Feb 19 00:03:54 2009
From: bogdan at voice-system.ro (Bogdan-Andrei Iancu)
Date: Thu, 19 Feb 2009 01:03:54 +0200
Subject: [OpenSIPS-Devel] When "make deb-etch" regex module is
	not	compiled
In-Reply-To: <200902182309.48910.ibc@aliax.net>
References: <200902182254.27994.ibc@aliax.net>	<8a4af3e20902181358w4a3d9a08sb8c44cfcb349c748@mail.gmail.com>
	<200902182309.48910.ibc@aliax.net>
Message-ID: <499C93DA.1000005@voice-system.ro>

Hi Inaki,

Sergio is right - the module does not appear in any deb package because 
the main "opensips" package contains only modules with no external 
dependencies. The module depending of other libs must have a separate 
package, so we need to create a new deb for the regex module.

I plan to update the deb specs as the regex module is not the only one 
in this situation.

Regards,
Bogdan

I?aki Baz Castillo wrote:
> El Mi?rcoles, 18 de Febrero de 2009, Sergio Gutierrez escribi?:
>   
>> Hi I?aki.
>>
>> I think it is because regex is not compiled by default because of its
>> dependency on pcre library.
>>     
>
> Hi Sergio, please chech ALL_MODULES value in debian/rules. All the modules 
> appear there, also those requiring external libraries.
>
> The "make deb-*" and normal "make" are very different since "make deb-*" tries 
> to compile most of the modules.
>
>
>   



From ibc at aliax.net  Thu Feb 19 00:11:33 2009
From: ibc at aliax.net (=?iso-8859-1?q?I=F1aki_Baz_Castillo?=)
Date: Thu, 19 Feb 2009 00:11:33 +0100
Subject: [OpenSIPS-Devel]
	=?iso-8859-1?q?When_=22make_deb-etch=22_regex_mo?=
	=?iso-8859-1?q?dule_is_not=09compiled?=
In-Reply-To: <499C93DA.1000005@voice-system.ro>
References: <200902182254.27994.ibc@aliax.net>
	<200902182309.48910.ibc@aliax.net>
	<499C93DA.1000005@voice-system.ro>
Message-ID: <200902190011.33206.ibc@aliax.net>

El Jueves, 19 de Febrero de 2009, Bogdan-Andrei Iancu escribi?:
> Hi Inaki,
>
> Sergio is right - the module does not appear in any deb package because
> the main "opensips" package contains only modules with no external
> dependencies. The module depending of other libs must have a separate
> package, so we need to create a new deb for the regex module.

Thanks, but just a question:
What about other modules compiled by default via "make deb*" as:
- mi_xmlrpc: depends on libxml, libxmlrpc-c3 and libxmlrpc-c3-dev
- uri_radius: depends on radiusclient-ng
- xcap_client: depends on libxml-dev, libcurl-dev
and so on?

-- 
I?aki Baz Castillo


From ibc at aliax.net  Thu Feb 19 00:23:55 2009
From: ibc at aliax.net (Inaki Baz Castillo)
Date: Wed, 18 Feb 2009 23:23:55 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[5342] trunk/modules/regex
Message-ID: <E1LZvlj-0004Px-1N@dn4whf1.ch3.sourceforge.com>

Revision: 5342
          http://opensips.svn.sourceforge.net/opensips/?rev=5342&view=rev
Author:   ibc_sf
Date:     2009-02-18 23:23:54 +0000 (Wed, 18 Feb 2009)

Log Message:
-----------
- Small typo in documentation (Example 1.11)

Modified Paths:
--------------
    trunk/modules/regex/README
    trunk/modules/regex/doc/regex_admin.xml


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


From saguti at gmail.com  Thu Feb 19 01:16:24 2009
From: saguti at gmail.com (Sergio Gutierrez)
Date: Thu, 19 Feb 2009 00:16:24 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[5343] trunk/modules/acc/doc
Message-ID: <E1LZwaW-0000K7-3Q@74yxhf1.ch3.sourceforge.com>

Revision: 5343
          http://opensips.svn.sourceforge.net/opensips/?rev=5343&view=rev
Author:   saguti
Date:     2009-02-19 00:16:23 +0000 (Thu, 19 Feb 2009)

Log Message:
-----------
- Fixed small typos.
- Fixed default value of service_type to make it consistent with code.

Modified Paths:
--------------
    trunk/modules/acc/doc/acc_admin.xml
    trunk/modules/acc/doc/acc_faq.xml


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


From saguti at gmail.com  Thu Feb 19 01:33:35 2009
From: saguti at gmail.com (Sergio Gutierrez)
Date: Thu, 19 Feb 2009 00:33:35 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[5344] trunk/modules/acc/doc
Message-ID: <E1LZwr9-000106-GQ@74yxhf1.ch3.sourceforge.com>

Revision: 5344
          http://opensips.svn.sourceforge.net/opensips/?rev=5344&view=rev
Author:   saguti
Date:     2009-02-19 00:33:35 +0000 (Thu, 19 Feb 2009)

Log Message:
-----------
- Fixed small typos in doc.

Modified Paths:
--------------
    trunk/modules/acc/doc/acc_admin.xml
    trunk/modules/acc/doc/acc_faq.xml


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


From saguti at gmail.com  Thu Feb 19 01:33:51 2009
From: saguti at gmail.com (Sergio Gutierrez)
Date: Thu, 19 Feb 2009 00:33:51 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[5345]
	branches/1.4/modules/acc/doc
Message-ID: <E1LZwrP-00010O-W2@74yxhf1.ch3.sourceforge.com>

Revision: 5345
          http://opensips.svn.sourceforge.net/opensips/?rev=5345&view=rev
Author:   saguti
Date:     2009-02-19 00:33:51 +0000 (Thu, 19 Feb 2009)

Log Message:
-----------
- Fixed small typos in doc.

Modified Paths:
--------------
    branches/1.4/modules/acc/doc/acc_admin.xml
    branches/1.4/modules/acc/doc/acc_faq.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 Feb 19 07:52:58 2009
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 19 Feb 2009 06:52:58 +0000
Subject: [OpenSIPS-Devel] [ opensips-Bugs-2608188 ] OpenSIPS latest trunk
	libmysqlclient segfault
Message-ID: <E1La2mI-0002l2-0h@b55xhf1.ch3.sourceforge.com>

Bugs item #2608188, was opened at 2009-02-17 06:02
Message generated for change (Comment added) made by nobody
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=2608188&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: 8
Private: No
Submitted By: Om Bikram Thapa (omthapa)
Assigned to: Bogdan-Andrei Iancu (bogdan_iancu)
Summary: OpenSIPS latest trunk libmysqlclient segfault 

Initial Comment:
OpenSIPS latest trunk on Debian Lenny/AMD64 dies with libmysqlclient segfault after a MySQL restart. The event that triggers this crash is registration related database query immediately after a MySQL restart. Once OpenSIPS is restarted after a crash, everything runs fine until next MySQL restart.

The log shows:

"opensips[16769]: segfault at 4c8 ip 7f36728bf283 sp 7fff7ba11a90 error 4 in libmysqlclient.so.15.0.0[7f3672862000+1bf000]"
 
and gdb bt gives following results:

---------------
Program terminated with signal 11, Segmentation fault.
[New process 16769]
#0  0x00007f36728bf283 in mysql_stmt_result_metadata ()
   from /usr/lib/libmysqlclient.so.15
(gdb) bt
#0  0x00007f36728bf283 in mysql_stmt_result_metadata ()
   from /usr/lib/libmysqlclient.so.15
#1  0x00007f3672c707b7 in db_mysql_do_prepared_query (conn=0x78b278, 
    query=<value optimized out>, v=0x7fff7ba11d20, n=1, uv=0x0, un=0)
    at dbase.c:363
#2  0x00007f3672c72e1f in db_mysql_query (_h=0x78b278, 
    _k=<value optimized out>, _op=<value optimized out>, _v=0x7fff7ba11d20, 
    _c=<value optimized out>, _n=1, _nc=2, _o=0x0, _r=0x7fff7ba11dc0)
    at dbase.c:591
#3  0x00007f366f3f0398 in authorize (_m=0x78fe98, 
    _realm=<value optimized out>, _table=<value optimized out>, 
    _hftype=<value optimized out>) at authorize.c:107
#4  0x000000000040f869 in do_action (a=0x780a48, msg=0x78fe98) at action.c:961
#5  0x000000000040e7e5 in run_action_list (a=<value optimized out>, 
    msg=0x78fe98) at action.c:139
#6  0x000000000046f194 in eval_elem (e=0x780b18, msg=0x78fe98, val=0x0)
    at route.c:1189
#7  0x00000000004708ed in eval_expr (e=0x120b1e0, msg=0x78fe98, val=0x0)
    at route.c:1486
#8  0x000000000047089c in eval_expr (e=0x780b60, msg=0x78fe98, val=0x0)
    at route.c:1502
#9  0x00000000004708c5 in eval_expr (e=0x780ba8, msg=0x78fe98, val=0x0)
    at route.c:1507
---Type <return> to continue, or q <return> to quit---
#10 0x000000000040f91c in do_action (a=0x780f40, msg=0x78fe98) at action.c:688
#11 0x000000000040e7e5 in run_action_list (a=<value optimized out>, 
    msg=0x78fe98) at action.c:139
#12 0x00000000004114d3 in do_action (a=0x781eb0, msg=0x78fe98) at action.c:705
#13 0x000000000040e7e5 in run_action_list (a=<value optimized out>, 
    msg=0x78fe98) at action.c:139
#14 0x0000000000410e07 in do_action (a=0x77ee88, msg=0x78fe98) at action.c:119
#15 0x000000000040e7e5 in run_action_list (a=<value optimized out>, 
    msg=0x78fe98) at action.c:139
#16 0x00000000004114d3 in do_action (a=0x77f028, msg=0x78fe98) at action.c:705
#17 0x000000000040e7e5 in run_action_list (a=<value optimized out>, 
    msg=0x78fe98) at action.c:139
#18 0x00000000004125fe in run_top_route (a=0x777e78, msg=0x78fe98)
    at action.c:119
#19 0x000000000045e898 in receive_msg (
    buf=0x749180 "REGISTER sip:x.x.x.x SIP/2.0\r\nCSeq: 2 REGISTER\r\nVia: SIP/2.0/UDP x.x.x.x:5061;branch=z9hG4bK60f1b2dd-57fa-dd11-9401-0015c5404858;rport\r\nUser-Agent: Ekiga/2.0.12\r\nAuthorization: Dige"..., 
    len=749, rcv_info=0x7fff7ba13530) at receive.c:165
#20 0x000000000049d3a6 in udp_rcv_loop () at udp_server.c:449
#21 0x00000000004291fb in main (argc=<value optimized out>, 
    argv=0x7fff7ba13718) at main.c:778
----------------


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

Comment By: Nobody/Anonymous (nobody)
Date: 2009-02-19 06:52

Message:
Hi Bogdan,

The issue remains with latest SVN also.

Here is the gdb trace now:

#0  0x00007f0119426283 in mysql_stmt_result_metadata () from
/usr/lib/libmysqlclient.so.15
(gdb) bt
#0  0x00007f0119426283 in mysql_stmt_result_metadata () from
/usr/lib/libmysqlclient.so.15
#1  0x00007f01197d8f82 in db_mysql_do_prepared_query (conn=0x78b278,
query=<value optimized out>, v=0x7fff22576880, n=<value optimized out>,
uv=0x0, un=0)
    at dbase.c:368
#2  0x00007f01197daccd in db_mysql_query (_h=0x78b278, _k=<value optimized
out>, _op=<value optimized out>, _v=0x7fff22576880, _c=<value optimized
out>, 
    _n=1, _nc=2, _o=0x0, _r=0x7fff22576920) at dbase.c:603
#3  0x00007f0115f56398 in authorize (_m=0x78fe98, _realm=<value optimized
out>, _table=<value optimized out>, _hftype=<value optimized out>)
    at authorize.c:107
#4  0x000000000040f869 in do_action (a=0x780a48, msg=0x78fe98) at
action.c:961
#5  0x000000000040e7e5 in run_action_list (a=<value optimized out>,
msg=0x78fe98) at action.c:139
#6  0x000000000046f194 in eval_elem (e=0x780b18, msg=0x78fe98, val=0x0) at
route.c:1189
#7  0x00000000004708ed in eval_expr (e=0x27648e0, msg=0x78fe98, val=0x0)
at route.c:1486
#8  0x000000000047089c in eval_expr (e=0x780b60, msg=0x78fe98, val=0x0) at
route.c:1502
#9  0x00000000004708c5 in eval_expr (e=0x780ba8, msg=0x78fe98, val=0x0) at
route.c:1507
#10 0x000000000040f91c in do_action (a=0x780f40, msg=0x78fe98) at
action.c:688
#11 0x000000000040e7e5 in run_action_list (a=<value optimized out>,
msg=0x78fe98) at action.c:139
#12 0x00000000004114d3 in do_action (a=0x781eb0, msg=0x78fe98) at
action.c:705
#13 0x000000000040e7e5 in run_action_list (a=<value optimized out>,
msg=0x78fe98) at action.c:139
#14 0x0000000000410e07 in do_action (a=0x77ee88, msg=0x78fe98) at
action.c:119
#15 0x000000000040e7e5 in run_action_list (a=<value optimized out>,
msg=0x78fe98) at action.c:139
#16 0x00000000004114d3 in do_action (a=0x77f028, msg=0x78fe98) at
action.c:705
#17 0x000000000040e7e5 in run_action_list (a=<value optimized out>,
msg=0x78fe98) at action.c:139
#18 0x00000000004125fe in run_top_route (a=0x777e78, msg=0x78fe98) at
action.c:119
#19 0x000000000045e898 in receive_msg (
    buf=0x749180 "REGISTER sip:x.x.x.x SIP/2.0\r\nCSeq: 58
REGISTER\r\nVia: SIP/2.0/UDP
x.x.x.x:5068;branch=z9hG4bK5ca4685b-befc-dd11-911f-0015c5404858;rport\r\nUser-Agent:
Ekiga/2.0.12\r\nAuthorization: Dig"..., len=750, rcv_info=0x7fff22578090)
at receive.c:165
#20 0x000000000049d3a6 in udp_rcv_loop () at udp_server.c:449
#21 0x00000000004291fb in main (argc=<value optimized out>,
argv=0x7fff22578278) at main.c:778


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

Comment By: Bogdan-Andrei Iancu (bogdan_iancu)
Date: 2009-02-18 21:02

Message:
Hi Om,

I hopefully fixed the problem - please update from SVN and give it another
try. Let me know if now works.

Thanks and regards,
Bogdan

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

Comment By: Om Bikram Thapa (omthapa)
Date: 2009-02-18 13:11

Message:
I modified domain in opensips domain table, immediately after that the
server crashed upon registration event with log  general protection
ip:7f249016986c sp:7fff992bf320 error:0 in
libmysqlclient.so.15.0.0[7f2490110000+1bf000]" and gdb backtrace now points
to different code:

----------
#0  0x00007f7a4c26f86c in mysql_stmt_fetch () from
/usr/lib/libmysqlclient.so.15
#1  0x00007f7a4c628a48 in db_mysql_convert_result (_h=0x78b278,
_r=0x78ba28) at res.c:161
#2  0x00007f7a4c626aaa in db_mysql_store_result (_h=0x78b278,
_r=0x7fff553c5770) at dbase.c:513
#3  0x00007f7a4c626e39 in db_mysql_query (_h=0x78b278, _k=<value optimized
out>, _op=<value optimized out>, _v=0x7fff553c56d0, _c=<value optimized
out>,
    _n=1, _nc=2, _o=0x0, _r=0x7fff553c5770) at dbase.c:593
#4  0x00007f7a48da4398 in authorize (_m=0x78fe98, _realm=<value optimized
out>, _table=<value optimized out>, _hftype=<value optimized out>)
    at authorize.c:107
#5  0x000000000040f869 in do_action (a=0x780a48, msg=0x78fe98) at
action.c:961
#6  0x000000000040e7e5 in run_action_list (a=<value optimized out>,
msg=0x78fe98) at action.c:139
#7  0x000000000046f194 in eval_elem (e=0x780b18, msg=0x78fe98, val=0x20)
at route.c:1189
#8  0x00000000004708ed in eval_expr (e=0xe543d0, msg=0x78fe98, val=0x0) at
route.c:1486
#9  0x000000000047089c in eval_expr (e=0x780b60, msg=0x78fe98, val=0x0) at
route.c:1502
#10 0x00000000004708c5 in eval_expr (e=0x780ba8, msg=0x78fe98, val=0x0) at
route.c:1507
#11 0x000000000040f91c in do_action (a=0x780f40, msg=0x78fe98) at
action.c:688
#12 0x000000000040e7e5 in run_action_list (a=<value optimized out>,
msg=0x78fe98) at action.c:139
#13 0x00000000004114d3 in do_action (a=0x781eb0, msg=0x78fe98) at
action.c:705
#14 0x000000000040e7e5 in run_action_list (a=<value optimized out>,
msg=0x78fe98) at action.c:139
#15 0x0000000000410e07 in do_action (a=0x77ee88, msg=0x78fe98) at
action.c:119
#16 0x000000000040e7e5 in run_action_list (a=<value optimized out>,
msg=0x78fe98) at action.c:139
#17 0x00000000004114d3 in do_action (a=0x77f028, msg=0x78fe98) at
action.c:705
#18 0x000000000040e7e5 in run_action_list (a=<value optimized out>,
msg=0x78fe98) at action.c:139
#19 0x00000000004125fe in run_top_route (a=0x777e78, msg=0x78fe98) at
action.c:119
#20 0x000000000045e898 in receive_msg (
    buf=0x749180 "REGISTER sip:x.x.x.x;transport=UDP SIP/2.0\r\nVia:
SIP/2.0/UDP
x.x.x.x:5060;branch=z9hG4bKgcjsr9edklicvlhif2tfvub;rport\r\nFrom:
<sip:300000 at x.x."..., len=693, rcv_info=0x7fff553c6ee0) at receive.c:165
#21 0x000000000049d3a6 in udp_rcv_loop () at udp_server.c:449
#22 0x00000000004291fb in main (argc=<value optimized out>,
argv=0x7fff553c70c8) at main.c:778
-----------------

I think this crash is also related to the same issue.

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

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


From noreply at sourceforge.net  Thu Feb 19 07:56:56 2009
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 19 Feb 2009 06:56:56 +0000
Subject: [OpenSIPS-Devel] [ opensips-Bugs-2608188 ] OpenSIPS latest trunk
	libmysqlclient segfault
Message-ID: <E1La2q8-00080V-Pl@h45xhf1.ch3.sourceforge.com>

Bugs item #2608188, was opened at 2009-02-17 06:02
Message generated for change (Comment added) made by nobody
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=2608188&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: 8
Private: No
Submitted By: Om Bikram Thapa (omthapa)
Assigned to: Bogdan-Andrei Iancu (bogdan_iancu)
Summary: OpenSIPS latest trunk libmysqlclient segfault 

Initial Comment:
OpenSIPS latest trunk on Debian Lenny/AMD64 dies with libmysqlclient segfault after a MySQL restart. The event that triggers this crash is registration related database query immediately after a MySQL restart. Once OpenSIPS is restarted after a crash, everything runs fine until next MySQL restart.

The log shows:

"opensips[16769]: segfault at 4c8 ip 7f36728bf283 sp 7fff7ba11a90 error 4 in libmysqlclient.so.15.0.0[7f3672862000+1bf000]"
 
and gdb bt gives following results:

---------------
Program terminated with signal 11, Segmentation fault.
[New process 16769]
#0  0x00007f36728bf283 in mysql_stmt_result_metadata ()
   from /usr/lib/libmysqlclient.so.15
(gdb) bt
#0  0x00007f36728bf283 in mysql_stmt_result_metadata ()
   from /usr/lib/libmysqlclient.so.15
#1  0x00007f3672c707b7 in db_mysql_do_prepared_query (conn=0x78b278, 
    query=<value optimized out>, v=0x7fff7ba11d20, n=1, uv=0x0, un=0)
    at dbase.c:363
#2  0x00007f3672c72e1f in db_mysql_query (_h=0x78b278, 
    _k=<value optimized out>, _op=<value optimized out>, _v=0x7fff7ba11d20, 
    _c=<value optimized out>, _n=1, _nc=2, _o=0x0, _r=0x7fff7ba11dc0)
    at dbase.c:591
#3  0x00007f366f3f0398 in authorize (_m=0x78fe98, 
    _realm=<value optimized out>, _table=<value optimized out>, 
    _hftype=<value optimized out>) at authorize.c:107
#4  0x000000000040f869 in do_action (a=0x780a48, msg=0x78fe98) at action.c:961
#5  0x000000000040e7e5 in run_action_list (a=<value optimized out>, 
    msg=0x78fe98) at action.c:139
#6  0x000000000046f194 in eval_elem (e=0x780b18, msg=0x78fe98, val=0x0)
    at route.c:1189
#7  0x00000000004708ed in eval_expr (e=0x120b1e0, msg=0x78fe98, val=0x0)
    at route.c:1486
#8  0x000000000047089c in eval_expr (e=0x780b60, msg=0x78fe98, val=0x0)
    at route.c:1502
#9  0x00000000004708c5 in eval_expr (e=0x780ba8, msg=0x78fe98, val=0x0)
    at route.c:1507
---Type <return> to continue, or q <return> to quit---
#10 0x000000000040f91c in do_action (a=0x780f40, msg=0x78fe98) at action.c:688
#11 0x000000000040e7e5 in run_action_list (a=<value optimized out>, 
    msg=0x78fe98) at action.c:139
#12 0x00000000004114d3 in do_action (a=0x781eb0, msg=0x78fe98) at action.c:705
#13 0x000000000040e7e5 in run_action_list (a=<value optimized out>, 
    msg=0x78fe98) at action.c:139
#14 0x0000000000410e07 in do_action (a=0x77ee88, msg=0x78fe98) at action.c:119
#15 0x000000000040e7e5 in run_action_list (a=<value optimized out>, 
    msg=0x78fe98) at action.c:139
#16 0x00000000004114d3 in do_action (a=0x77f028, msg=0x78fe98) at action.c:705
#17 0x000000000040e7e5 in run_action_list (a=<value optimized out>, 
    msg=0x78fe98) at action.c:139
#18 0x00000000004125fe in run_top_route (a=0x777e78, msg=0x78fe98)
    at action.c:119
#19 0x000000000045e898 in receive_msg (
    buf=0x749180 "REGISTER sip:x.x.x.x SIP/2.0\r\nCSeq: 2 REGISTER\r\nVia: SIP/2.0/UDP x.x.x.x:5061;branch=z9hG4bK60f1b2dd-57fa-dd11-9401-0015c5404858;rport\r\nUser-Agent: Ekiga/2.0.12\r\nAuthorization: Dige"..., 
    len=749, rcv_info=0x7fff7ba13530) at receive.c:165
#20 0x000000000049d3a6 in udp_rcv_loop () at udp_server.c:449
#21 0x00000000004291fb in main (argc=<value optimized out>, 
    argv=0x7fff7ba13718) at main.c:778
----------------


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

Comment By: Nobody/Anonymous (nobody)
Date: 2009-02-19 06:56

Message:
Hi Bogdan,

The issue remains with latest SVN also.

Here is the gdb trace now:

#0  0x00007f0119426283 in mysql_stmt_result_metadata () from
/usr/lib/libmysqlclient.so.15
(gdb) bt
#0  0x00007f0119426283 in mysql_stmt_result_metadata () from
/usr/lib/libmysqlclient.so.15
#1  0x00007f01197d8f82 in db_mysql_do_prepared_query (conn=0x78b278,
query=<value optimized out>, v=0x7fff22576880, n=<value optimized out>,
uv=0x0, un=0)
    at dbase.c:368
#2  0x00007f01197daccd in db_mysql_query (_h=0x78b278, _k=<value optimized
out>, _op=<value optimized out>, _v=0x7fff22576880, _c=<value optimized
out>, 
    _n=1, _nc=2, _o=0x0, _r=0x7fff22576920) at dbase.c:603
#3  0x00007f0115f56398 in authorize (_m=0x78fe98, _realm=<value optimized
out>, _table=<value optimized out>, _hftype=<value optimized out>)
    at authorize.c:107
#4  0x000000000040f869 in do_action (a=0x780a48, msg=0x78fe98) at
action.c:961
#5  0x000000000040e7e5 in run_action_list (a=<value optimized out>,
msg=0x78fe98) at action.c:139
#6  0x000000000046f194 in eval_elem (e=0x780b18, msg=0x78fe98, val=0x0) at
route.c:1189
#7  0x00000000004708ed in eval_expr (e=0x27648e0, msg=0x78fe98, val=0x0)
at route.c:1486
#8  0x000000000047089c in eval_expr (e=0x780b60, msg=0x78fe98, val=0x0) at
route.c:1502
#9  0x00000000004708c5 in eval_expr (e=0x780ba8, msg=0x78fe98, val=0x0) at
route.c:1507
#10 0x000000000040f91c in do_action (a=0x780f40, msg=0x78fe98) at
action.c:688
#11 0x000000000040e7e5 in run_action_list (a=<value optimized out>,
msg=0x78fe98) at action.c:139
#12 0x00000000004114d3 in do_action (a=0x781eb0, msg=0x78fe98) at
action.c:705
#13 0x000000000040e7e5 in run_action_list (a=<value optimized out>,
msg=0x78fe98) at action.c:139
#14 0x0000000000410e07 in do_action (a=0x77ee88, msg=0x78fe98) at
action.c:119
#15 0x000000000040e7e5 in run_action_list (a=<value optimized out>,
msg=0x78fe98) at action.c:139
#16 0x00000000004114d3 in do_action (a=0x77f028, msg=0x78fe98) at
action.c:705
#17 0x000000000040e7e5 in run_action_list (a=<value optimized out>,
msg=0x78fe98) at action.c:139
#18 0x00000000004125fe in run_top_route (a=0x777e78, msg=0x78fe98) at
action.c:119
#19 0x000000000045e898 in receive_msg (
    buf=0x749180 "REGISTER sip:x.x.x.x SIP/2.0\r\nCSeq: 58
REGISTER\r\nVia: SIP/2.0/UDP
x.x.x.x:5068;branch=z9hG4bK5ca4685b-befc-dd11-911f-0015c5404858;rport\r\nUser-Agent:
Ekiga/2.0.12\r\nAuthorization: Dig"..., len=750, rcv_info=0x7fff22578090)
at receive.c:165
#20 0x000000000049d3a6 in udp_rcv_loop () at udp_server.c:449
#21 0x00000000004291fb in main (argc=<value optimized out>,
argv=0x7fff22578278) at main.c:778


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

Comment By: Nobody/Anonymous (nobody)
Date: 2009-02-19 06:52

Message:
Hi Bogdan,

The issue remains with latest SVN also.

Here is the gdb trace now:

#0  0x00007f0119426283 in mysql_stmt_result_metadata () from
/usr/lib/libmysqlclient.so.15
(gdb) bt
#0  0x00007f0119426283 in mysql_stmt_result_metadata () from
/usr/lib/libmysqlclient.so.15
#1  0x00007f01197d8f82 in db_mysql_do_prepared_query (conn=0x78b278,
query=<value optimized out>, v=0x7fff22576880, n=<value optimized out>,
uv=0x0, un=0)
    at dbase.c:368
#2  0x00007f01197daccd in db_mysql_query (_h=0x78b278, _k=<value optimized
out>, _op=<value optimized out>, _v=0x7fff22576880, _c=<value optimized
out>, 
    _n=1, _nc=2, _o=0x0, _r=0x7fff22576920) at dbase.c:603
#3  0x00007f0115f56398 in authorize (_m=0x78fe98, _realm=<value optimized
out>, _table=<value optimized out>, _hftype=<value optimized out>)
    at authorize.c:107
#4  0x000000000040f869 in do_action (a=0x780a48, msg=0x78fe98) at
action.c:961
#5  0x000000000040e7e5 in run_action_list (a=<value optimized out>,
msg=0x78fe98) at action.c:139
#6  0x000000000046f194 in eval_elem (e=0x780b18, msg=0x78fe98, val=0x0) at
route.c:1189
#7  0x00000000004708ed in eval_expr (e=0x27648e0, msg=0x78fe98, val=0x0)
at route.c:1486
#8  0x000000000047089c in eval_expr (e=0x780b60, msg=0x78fe98, val=0x0) at
route.c:1502
#9  0x00000000004708c5 in eval_expr (e=0x780ba8, msg=0x78fe98, val=0x0) at
route.c:1507
#10 0x000000000040f91c in do_action (a=0x780f40, msg=0x78fe98) at
action.c:688
#11 0x000000000040e7e5 in run_action_list (a=<value optimized out>,
msg=0x78fe98) at action.c:139
#12 0x00000000004114d3 in do_action (a=0x781eb0, msg=0x78fe98) at
action.c:705
#13 0x000000000040e7e5 in run_action_list (a=<value optimized out>,
msg=0x78fe98) at action.c:139
#14 0x0000000000410e07 in do_action (a=0x77ee88, msg=0x78fe98) at
action.c:119
#15 0x000000000040e7e5 in run_action_list (a=<value optimized out>,
msg=0x78fe98) at action.c:139
#16 0x00000000004114d3 in do_action (a=0x77f028, msg=0x78fe98) at
action.c:705
#17 0x000000000040e7e5 in run_action_list (a=<value optimized out>,
msg=0x78fe98) at action.c:139
#18 0x00000000004125fe in run_top_route (a=0x777e78, msg=0x78fe98) at
action.c:119
#19 0x000000000045e898 in receive_msg (
    buf=0x749180 "REGISTER sip:x.x.x.x SIP/2.0\r\nCSeq: 58
REGISTER\r\nVia: SIP/2.0/UDP
x.x.x.x:5068;branch=z9hG4bK5ca4685b-befc-dd11-911f-0015c5404858;rport\r\nUser-Agent:
Ekiga/2.0.12\r\nAuthorization: Dig"..., len=750, rcv_info=0x7fff22578090)
at receive.c:165
#20 0x000000000049d3a6 in udp_rcv_loop () at udp_server.c:449
#21 0x00000000004291fb in main (argc=<value optimized out>,
argv=0x7fff22578278) at main.c:778


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

Comment By: Bogdan-Andrei Iancu (bogdan_iancu)
Date: 2009-02-18 21:02

Message:
Hi Om,

I hopefully fixed the problem - please update from SVN and give it another
try. Let me know if now works.

Thanks and regards,
Bogdan

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

Comment By: Om Bikram Thapa (omthapa)
Date: 2009-02-18 13:11

Message:
I modified domain in opensips domain table, immediately after that the
server crashed upon registration event with log  general protection
ip:7f249016986c sp:7fff992bf320 error:0 in
libmysqlclient.so.15.0.0[7f2490110000+1bf000]" and gdb backtrace now points
to different code:

----------
#0  0x00007f7a4c26f86c in mysql_stmt_fetch () from
/usr/lib/libmysqlclient.so.15
#1  0x00007f7a4c628a48 in db_mysql_convert_result (_h=0x78b278,
_r=0x78ba28) at res.c:161
#2  0x00007f7a4c626aaa in db_mysql_store_result (_h=0x78b278,
_r=0x7fff553c5770) at dbase.c:513
#3  0x00007f7a4c626e39 in db_mysql_query (_h=0x78b278, _k=<value optimized
out>, _op=<value optimized out>, _v=0x7fff553c56d0, _c=<value optimized
out>,
    _n=1, _nc=2, _o=0x0, _r=0x7fff553c5770) at dbase.c:593
#4  0x00007f7a48da4398 in authorize (_m=0x78fe98, _realm=<value optimized
out>, _table=<value optimized out>, _hftype=<value optimized out>)
    at authorize.c:107
#5  0x000000000040f869 in do_action (a=0x780a48, msg=0x78fe98) at
action.c:961
#6  0x000000000040e7e5 in run_action_list (a=<value optimized out>,
msg=0x78fe98) at action.c:139
#7  0x000000000046f194 in eval_elem (e=0x780b18, msg=0x78fe98, val=0x20)
at route.c:1189
#8  0x00000000004708ed in eval_expr (e=0xe543d0, msg=0x78fe98, val=0x0) at
route.c:1486
#9  0x000000000047089c in eval_expr (e=0x780b60, msg=0x78fe98, val=0x0) at
route.c:1502
#10 0x00000000004708c5 in eval_expr (e=0x780ba8, msg=0x78fe98, val=0x0) at
route.c:1507
#11 0x000000000040f91c in do_action (a=0x780f40, msg=0x78fe98) at
action.c:688
#12 0x000000000040e7e5 in run_action_list (a=<value optimized out>,
msg=0x78fe98) at action.c:139
#13 0x00000000004114d3 in do_action (a=0x781eb0, msg=0x78fe98) at
action.c:705
#14 0x000000000040e7e5 in run_action_list (a=<value optimized out>,
msg=0x78fe98) at action.c:139
#15 0x0000000000410e07 in do_action (a=0x77ee88, msg=0x78fe98) at
action.c:119
#16 0x000000000040e7e5 in run_action_list (a=<value optimized out>,
msg=0x78fe98) at action.c:139
#17 0x00000000004114d3 in do_action (a=0x77f028, msg=0x78fe98) at
action.c:705
#18 0x000000000040e7e5 in run_action_list (a=<value optimized out>,
msg=0x78fe98) at action.c:139
#19 0x00000000004125fe in run_top_route (a=0x777e78, msg=0x78fe98) at
action.c:119
#20 0x000000000045e898 in receive_msg (
    buf=0x749180 "REGISTER sip:x.x.x.x;transport=UDP SIP/2.0\r\nVia:
SIP/2.0/UDP
x.x.x.x:5060;branch=z9hG4bKgcjsr9edklicvlhif2tfvub;rport\r\nFrom:
<sip:300000 at x.x."..., len=693, rcv_info=0x7fff553c6ee0) at receive.c:165
#21 0x000000000049d3a6 in udp_rcv_loop () at udp_server.c:449
#22 0x00000000004291fb in main (argc=<value optimized out>,
argv=0x7fff553c70c8) at main.c:778
-----------------

I think this crash is also related to the same issue.

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

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


From bogdan at voice-system.ro  Thu Feb 19 11:07:08 2009
From: bogdan at voice-system.ro (Bogdan-Andrei Iancu)
Date: Thu, 19 Feb 2009 12:07:08 +0200
Subject: [OpenSIPS-Devel] When "make deb-etch" regex module is not
	compiled
In-Reply-To: <200902190011.33206.ibc@aliax.net>
References: <200902182254.27994.ibc@aliax.net>	<200902182309.48910.ibc@aliax.net>	<499C93DA.1000005@voice-system.ro>
	<200902190011.33206.ibc@aliax.net>
Message-ID: <499D2F4C.1030107@voice-system.ro>

Hi Inaki,

I?aki Baz Castillo wrote:
> El Jueves, 19 de Febrero de 2009, Bogdan-Andrei Iancu escribi?:
>   
>> Hi Inaki,
>>
>> Sergio is right - the module does not appear in any deb package because
>> the main "opensips" package contains only modules with no external
>> dependencies. The module depending of other libs must have a separate
>> package, so we need to create a new deb for the regex module.
>>     
>
> Thanks, but just a question:
> What about other modules compiled by default via "make deb*" as:
> - mi_xmlrpc: depends on libxml, libxmlrpc-c3 and libxmlrpc-c3-dev
>   
there is the separate opensips-xmlrpc package
> - uri_radius: depends on radiusclient-ng
>   
opensips-radius package
> - xcap_client: depends on libxml-dev, libcurl-dev
> and so on?
>   
in opensips-presence package

Regards,
Bogdan



From ibc at aliax.net  Thu Feb 19 11:52:48 2009
From: ibc at aliax.net (=?UTF-8?Q?I=C3=B1aki_Baz_Castillo?=)
Date: Thu, 19 Feb 2009 11:52:48 +0100
Subject: [OpenSIPS-Devel] When "make deb-etch" regex module is not
	compiled
In-Reply-To: <499D2F4C.1030107@voice-system.ro>
References: <200902182254.27994.ibc@aliax.net>
	<200902182309.48910.ibc@aliax.net> <499C93DA.1000005@voice-system.ro>
	<200902190011.33206.ibc@aliax.net> <499D2F4C.1030107@voice-system.ro>
Message-ID: <cc1f582e0902190252v417225e3r4cd52bb7b3b2de0@mail.gmail.com>

2009/2/19 Bogdan-Andrei Iancu <bogdan at voice-system.ro>:
>> Thanks, but just a question:
>> What about other modules compiled by default via "make deb*" as:
>> - mi_xmlrpc: depends on libxml, libxmlrpc-c3 and libxmlrpc-c3-dev
>>
>
> there is the separate opensips-xmlrpc package
>>
>> - uri_radius: depends on radiusclient-ng
>>
>
> opensips-radius package
>>
>> - xcap_client: depends on libxml-dev, libcurl-dev
>> and so on?
>>
>
> in opensips-presence package


:)

Thanks, I was wrong.


-- 
I?aki Baz Castillo
<ibc at aliax.net>


From noreply at sourceforge.net  Thu Feb 19 13:03:35 2009
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 19 Feb 2009 12:03:35 +0000
Subject: [OpenSIPS-Devel] [ opensips-Bugs-2523454 ] Error in handling rls
	NOTIFY
Message-ID: <E1La7ct-0004qp-KA@cdv4jf1.ch3.sourceforge.com>

Bugs item #2523454, was opened at 2009-01-20 13:55
Message generated for change (Comment added) made by anca_vamanu
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=2523454&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: Nathan (rmnathan)
Assigned to: Anca Vamanu (anca_vamanu)
Summary: Error in handling rls NOTIFY

Initial Comment:
Hi
The following error message are printed while handling rls notify.
Jan 20 06:45:44 [7833] ERROR:rls:parse_subs_state: terminated state and no reason foundJan 20 06:45:44 [7833] ERROR:rls:rls_handle_notify: while parsing 'Subscription-State' header
Jan 20 06:45:44 [7833] ERROR:rls:parse_subs_state: terminated state and no reason foundJan 20 06:45:44 [7833] ERROR:rls:rls_handle_notify: while parsing 'Subscription-State' header
Jan 20 06:45:44 [7833] ERROR:rls:parse_subs_state: terminated state and no reason foundJan 20 06:45:44 [7833] ERROR:rls:rls_handle_notify: while parsing 'Subscription-State' header
Jan 20 06:45:52 [7833] ERROR:rls:parse_subs_state: terminated state and no reason foundJan 20 06:45:52 [7833] ERROR:rls:rls_handle_notify: while parsing 'Subscription-State' header
Jan 20 06:45:52 [7833] ERROR:rls:parse_subs_state: terminated state and no reason foundJan 20 06:45:52 [7833] ERROR:rls:rls_handle_notify: while parsing 'Subscription-State' header
Jan 20 06:46:13 [7834] ERROR:core:db_do_insert: invalid parameter value
Jan 20 06:46:13 [7834] ERROR:pua:db_update: while inserting in db table pua
Jan 20 06:46:43 [7834] ERROR:core:parse_uri: uri too short: <> (0)
Jan 20 06:46:43 [7834] ERROR:tm:uri2proxy: bad_uri:
Jan 20 06:46:43 [7834] ERROR:tm:uri2su: failed create a dst proxy
Jan 20 06:46:43 [7834] ERROR:tm:t_uac: no socket found
Jan 20 06:46:43 [7834] ERROR:pua:update_pua: in t_request function
Jan 20 06:46:43 [7834] ERROR:pua:hashT_clean: while updating record
Jan 20 06:47:05 [7833] ERROR:rls:parse_subs_state: terminated state and no reason foundJan 20 06:47:05 [7833] ERROR:rls:rls_handle_notify: while parsing 'Subscription-State' header

Regards,
rmnathan


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

>Comment By: Anca Vamanu (anca_vamanu)
Date: 2009-02-19 14:03

Message:
Hi Rmnathan,

I looked through your trace but something is confusing.
Can you please tell me what was running on 192.168.166.150 port 50606. I
see that the User-Agent header is OpenSIPS, but the behavior doesn't seem
like that of a presence or rls server.

regards,
Anca

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

Comment By: Nathan (rmnathan)
Date: 2009-02-02 11:14

Message:
Hi Anca.
Yes, am using opensips as presence server and rls server. Please find the
logs and pcap file for call flow attached.

Regards,
rmnathan


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

Comment By: Anca Vamanu (anca_vamanu)
Date: 2009-01-22 15:25

Message:
Hi rmnathan,

Thank you for this report also.
There is something wrong with that Notify that gives this error.
Can you please trace the trafic and catch a Notify that generates this
error and print it here?
This Notify is received from the presence server. Are you using also
OpenSIPS as the presence server? Can you please check is the source IP
address of the Notify message is that of the presence server?

regards,
Anca

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

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


From noreply at sourceforge.net  Thu Feb 19 13:05:45 2009
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 19 Feb 2009 12:05:45 +0000
Subject: [OpenSIPS-Devel] [ opensips-Bugs-2430807 ] Opensips crashes when
	publish received for RLS list
Message-ID: <E1La7ez-0001R2-3e@155xhf1.ch3.sourceforge.com>

Bugs item #2430807, was opened at 2008-12-15 13:04
Message generated for change (Comment added) made by anca_vamanu
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=2430807&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: 8
Private: No
Submitted By: Nathan (rmnathan)
Assigned to: Anca Vamanu (anca_vamanu)
Summary: Opensips crashes when publish received for RLS list

Initial Comment:
Version - trunk(5049)
I have tried all sort of following thing to generate core . But it failed to generate core dump.
1.  disable_core_dump is set to no
2. set fork=no and child=no
3. tried to find core dump  at /
4. compiled opensips with the following command
    make mode=debug modules
    echo $?
    make mode=debug prefix=/usr/local/ install
5. OS stinbng46:/# uname -a
Linux stinbng46 2.6.18-staros-v2-20294-deb #1 SMP Mon Jul 14 05:18:18 EDT 2008 i686 GNU/Linux ( With same OS openser created core dump)

Is there any anything I might be missing? please help me to generate core dump , it will be very helpful for debugging.

Crash:
=====
Crash observed when notify sent out for RLS list in case of PUBLISH received. for more information please find the attached logs.

Dec 15 05:12:44 [15278] DBG:core:parse_uri:  uri params:
   transport=<>, val=<>, proto=0
Dec 15 05:12:44 [15278] DBG:core:parse_uri:    user-param=<>, val=<>
Dec 15 05:12:44 [15278] DBG:core:parse_uri:    method=<>, val=<>
Dec 15 05:12:44 [15278] DBG:core:parse_uri:    ttl=<>, val=<>
Dec 15 05:12:44 [15278] DBG:core:parse_uri:    maddr=<>, val=<>
Dec 15 05:12:44 [15278] DBG:core:parse_uri:    lr=<lr>
Dec 15 05:12:44 [15278] DBG:core:mk_proxy: doing DNS lookup...
Dec 15 05:12:44 [15278] DBG:tm:dlg2hash: 21643
Dec 15 05:12:44 [15278] DBG:tm:print_request_uri: sip:c3-1 at 192.168.126.151:40000
Dec 15 05:12:44 [15278] DBG:tm:set_timer: relative timeout is 500000
Dec 15 05:12:44 [15278] DBG:tm:insert_timer_unsafe: [4]: 0xb5be4a64 (20500000)
Dec 15 05:12:44 [15278] DBG:tm:set_timer: relative timeout is 30
Dec 15 05:12:44 [15278] DBG:tm:insert_timer_unsafe: [0]: 0xb5be4a84 (50)
Dec 15 05:12:44 [15278] DBG:rls:timer_send_notify: Found rl-subs record in hash table
Dec 15 05:12:44 [15277] INFO:core:handle_sigs: child process 15278 exited by a signal 11
Dec 15 05:12:44 [15277] INFO:core:handle_sigs: core was not generated
Dec 15 05:12:44 [15277] INFO:core:handle_sigs: terminating due to SIGCHLD
Dec 15 05:12:44 [15279] INFO:core:sig_usr: signal 15 received

Dec 15 05:12:44 [15277] DBG:core:shm_mem_destroy:
Dec 15 05:12:44 [15277] DBG:core:shm_mem_destroy: destroying the shared memory lock
Dec 15 05:12:44 [15277] DBG:core:handle_sigs: terminating due to SIGCHLD

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

>Comment By: Anca Vamanu (anca_vamanu)
Date: 2009-02-19 14:05

Message:
Hi,

I will close this bug report as the initial issue has been solved and the
Notify error reported later is discussed in another bug report.

Anca

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

Comment By: Anca Vamanu (anca_vamanu)
Date: 2009-02-06 20:21

Message:
Sorry I did not see that you included a trace in bug #2523454 :). I will
take a look at that.

regards,
Anca

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

Comment By: Anca Vamanu (anca_vamanu)
Date: 2009-02-06 20:17

Message:
Hi rmnathan,

As I have asked in a previous post, please try to catch the Notify that
generates this error so I can investigate.

regards,
Anca

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

Comment By: Nathan (rmnathan)
Date: 2009-02-02 11:04

Message:
Hi Anca,
I have tested with new clone . The crash is not observed. but i have seen
lot of error message like beow. I will update log and call flow for this
error message in the respective bug item.

Feb  2 14:26:28 [26461] ERROR:rls:parse_subs_state: terminated state and
no reason foundFeb  2 14:26:28 [26461] ERROR:rls:rls_handle_notify: while
parsing 'Subscription-State' header
Feb  2 14:26:28 [26461] ERROR:rls:parse_subs_state: terminated state and
no reason foundFeb  2 14:26:28 [26461] ERROR:rls:rls_handle_notify: while
parsing 'Subscription-State' header
Feb  2 14:26:29 [26461] ERROR:rls:rls_notify_callback: record not found in
hash table
Feb  2 14:26:34 [26461] ERROR:rls:parse_subs_state: terminated state and
no reason foundFeb  2 14:26:34 [26461] ERROR:rls:rls_handle_notify: while
parsing 'Subscription-State' header
Feb  2 14:26:34 [26461] ERROR:rls:parse_subs_state: terminated state and
no reason foundFeb  2 14:26:34 [26461] ERROR:rls:rls_handle_notify: while
parsing 'Subscription-State' header

Thanks lot

Regards,
rmnathan

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

Comment By: Anca Vamanu (anca_vamanu)
Date: 2009-01-23 15:16

Message:
Hi Rmnathan,

Yesterday I have found a double free bug in rls module. Can you please
update your version and test again?

Thanks and regards,
Anca

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

Comment By: Nathan (rmnathan)
Date: 2009-01-22 08:53

Message:
Hi Anca,
Any update on this issue?

Regards,
rmnathan

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

Comment By: Nobody/Anonymous (nobody)
Date: 2009-01-12 15:55

Message:
Hi Anca,
The details of error message and call scenario as follows

1.Error Message
=================
 Only following error message is getting at the time of crashing
Jan 12 08:20:10 [27860] WARNING:core:main: no fork mode
Jan 12 08:21:10 [27860] ERROR:core:db_do_insert: invalid parameter value
Jan 12 08:21:10 [27860] ERROR:pua:db_update: while inserting in db table
pua

2. Setup details
=================
UE 1 
	-------	   PROXY  --------- Opensips
UE 2 

Note : All users are in same domain

UE 2 will have following list in openxcap table
----------------------------------------------------
It has 100 list  for each user

 uE2_1, UE2_2, UE2_3 ..
UE2_1 list will have 5 entry uri like UE1_1,UE1_2,UE1_3,UE1_4,UE1_5
UE2_2 list will have 5 entry uri like UE1_2,UE1_3,UE1_4,UE1_5,UE1_6
simillary it will go for 100 user
.
.
UE2_100 list will have 5 entry uri like UE1_100,UE1_1,UE1_2,UE1_3,UE1_4

UE 1 will have following list in openxcap table
----------------------------------------------------
It has 100 list  for each user

 uE2_1, UE2_2, UE2_3 ..
UE1_1 list will have 5 entry uri like UE2_1,UE2_2,UE2_3,UE2_4,UE2_5
UE1_2 list will have 5 entry uri like UE2_2,UE2_3,UE2_4,UE2_5,UE2_6
simillary it will go for 100 user
.
.

UE1_100 list will have 5 entry uri like UE2_100,UE2_1,UE2_2,UE2_3,UE2_4


Sample Message flow for UE1 for one user 
========================================

1. UE 1(UE1_1) will send subscribe message to rls list UE1_1 
2. UE 1 will send publish 

simillary UE2_1 .. will send subscribe and publish.


Regards,
rmnathan

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

Comment By: Anca Vamanu (anca_vamanu)
Date: 2009-01-08 18:06

Message:
Hi,

I did not succeeded to get segmentation fault on my machine or to detect
the problem in the code and from your trace. Can you please tell me if see
any errors in you log file? And what scenario are you using when testing?

regards,
Anca



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

Comment By: Nathan (rmnathan)
Date: 2009-01-07 14:52

Message:
crash 2 with full bt trace
===================
error message before crashing:
Jan  7 07:21:05 [10134] ERROR:core:db_do_insert: invalid parameter value
Jan  7 07:21:05 [10134] ERROR:pua:db_update: while inserting in db table
pua

Core was generated by `/usr/local/sbin/opensips -m 1024'.
Program terminated with signal 11, Segmentation fault.
#0  fm_malloc (qm=0x81a3ba0, size=1528) at mem/f_malloc.c:267
267                             if ((*f)->size>=size) goto found;
(gdb) bt full
#0  fm_malloc (qm=0x81a3ba0, size=1528) at mem/f_malloc.c:267
        f = (struct fm_frag **) 0x81a4330
        hash = 239
#1  0xb78f1b51 in agg_body_sendn_update (rl_uri=0x81b31b0,
boundary_string={s = 0x81b1970 "gQIIPDYu2UDVZoZv5NTp3DgT", len = 24},
rlmi_body=0xbf9ad484,
    multipart_body=0xbf9ad47c, subs=0x81b31b0, hash_code=1381) at
notify.c:238
        cid = {s = 0x81b1c50 "1231330858.sip:c5-1 at 10.6.2.246.1189641421",
len = 41}
        len = 1526
        body = {s = 0x0, len = 0}
        __FUNCTION__ = "agg_body_sendn_update"
#2  0xb78f4efe in timer_send_notify (ticks=180, param=0x0) at
resource_notify.c:544
        query_cols = {0xb7906844, 0xb7ab9510}
        update_cols = {0xb7906844}
        result_cols = {0xb7906834, 0xb790683c, 0xb790684c, 0xb790685c,
0xb7906854, 0xb7906864, 0x0}
        query_vals = {{type = DB_INT, nul = 0, free = 2007220120, val =
{int_val = 1, double_val = 1.6975966328216244e-313, time_val = 1,
      string_val = 0x1 <Address 0x1 out of bounds>, str_val = {s = 0x1
<Address 0x1 out of bounds>, len = 8}, blob_val = {
        s = 0x1 <Address 0x1 out of bounds>, len = 8}, bitmap_val = 1}},
{type = 135996560, nul = 0, free = -1080372044, val = {int_val = 135974160,
      double_val = 6.7180161178120992e-316, time_val = 135974160,
string_val = 0x81acd10 "?\225??", str_val = {s = 0x81acd10 "?\225??",
len = 0},
      blob_val = {s = 0x81acd10 "?\225??", len = 0}, bitmap_val =
135974160}}}
        update_vals = {{type = DB_DATETIME, nul = 2007220120, free =
-1213492080, val = {int_val = -1, double_val = -1.5830897899132156e-40,
time_val = -1,
      string_val = 0xffffffff <Address 0xffffffff out of bounds>, str_val
= {s = 0xffffffff <Address 0xffffffff out of bounds>, len = -1213492016},
      blob_val = {s = 0xffffffff <Address 0xffffffff out of bounds>, len =
-1213492016}, bitmap_val = 4294967295}}}
        i = 5
        result = (db_res_t *) 0x81b1768
        prev_did = 0x481c5c3c
"c5-1-80;227413568;97b57f2144c425bc44f2e7a21eb22549-57d9"
        curr_did = 0x481c601c
"c6-1-80;227413312;97b57f2144c425bc44f2e7a21eb22549-4c39"
        row_vals = (db_val_t *) 0x81b2d78
        resource_uri = 0x481c6054 "sip:s6-1 at 10.6.2.246"
        pres_state = 0x481c6080 "<?xml version=\"1.0\"
encoding=\"UTF-8\"?>\n<presence xmlns=\"urn:ietf:params:xml:ns:pidf\"
xmlns:rpid=\"urn:ietf:params:xml:ns:pidf:rpid\"
xmlns:dm=\"urn:ietf:params:xml:ns:pidf:data-model\"
xmlns:pcp=\"urn:ietf"...
        callid = {s = 0x481c5c3c
"c5-1-80;227413568;97b57f2144c425bc44f2e7a21eb22549-57d9", len = 7}
        to_tag = {s = 0x481c5c4e "97b57f2144c425bc44f2e7a21eb22549-57d9",
len = 37}
        from_tag = {s = 0x481c5c44
"227413568;97b57f2144c425bc44f2e7a21eb22549-57d9", len = 9}
        rlmi_doc = (xmlDocPtr) 0x481af758
        list_node = (xmlNodePtr) 0x481accb8
        instance_node = (xmlNodePtr) 0x481af9a0
        resource_node = (xmlNodePtr) 0x481af8b0
        hash_code = 1381
        size = 2048
        buf_len = 1004
        buf = 0x81b3380
"--gQIIPDYu2UDVZoZv5NTp3DgT\r\n\r\nContent-Transfer-Encoding:
binary\r\nContent-ID:
<1231330858.sip:s5-1 at 10.6.2.246.596516649>\r\nContent-Type:
application/pidf+xml\r\n\r\n<?xml version=\"1.0\"
encoding=\"UTF-8\"?>\n<p"...
        auth_state = <value optimized out>
        contor = 1
        auth_state_flag = 2
        bstr = {s = 0x81b1970 "gQIIPDYu2UDVZoZv5NTp3DgT", len = 24}
        rlmi_cont = {
  s = 0x481aed98 "<?xml version=\"1.0\"?>\n<list
uri=\"sip:c5-1 at 10.6.2.246\" xmlns=\"urn:ietf:params:xml:ns:rlmi\"
version=\"5\" fullState=\"false\">\n  <resource
uri=\"sip:s5-1 at 10.6.2.246\">\n    <instance id=\"icDW4oK5\"
state=\"activ"..., len = 274}
        multi_cont = {
  s = 0x81b3380
"--gQIIPDYu2UDVZoZv5NTp3DgT\r\n\r\nContent-Transfer-Encoding:
binary\r\nContent-ID:
<1231330858.sip:s5-1 at 10.6.2.246.596516649>\r\nContent-Type:
application/pidf+xml\r\n\r\n<?xml version=\"1.0\"
encoding=\"UTF-8\"?>\n<p"..., len = 1004}
        s = (subs_t *) 0x77af7598
        dialog = (subs_t *) 0x81b31b0
        rl_uri = 0x81b2a80 "sip:c5-1 at 10.6.2.246"
        str_aux = <value optimized out>
        __FUNCTION__ = "timer_send_notify"
#3  0x080ccfb5 in start_timer_processes () at timer.c:280
---Type <return> to continue, or q <return> to quit---
        tpl = (struct sr_timer_process *) 0x81acad8
        pid = <value optimized out>
        first = <value optimized out>
        __FUNCTION__ = "start_timer_processes"
#4  0x0806f189 in main (argc=3, argv=0xbf9ad664) at main.c:666
        cfg_log_stderr = 0
        cfg_stream = (FILE *) 0x481a4008
        c = <value optimized out>
        r = <value optimized out>
        tmp = 0xbf9aedec ""
        tmp_len = <value optimized out>
        port = <value optimized out>
        proto = <value optimized out>
        ret = <value optimized out>
        seed = 4221279407
        rfd = 4
        __FUNCTION__ = "main"
(gdb)

crash 3 with full bt trace
===================
error message before crashing:
Jan  7 07:29:00 [10190] ERROR:db_mysql:db_mysql_str2val: invalid parameter
value
Jan  7 07:29:00 [10190] ERROR:db_mysql:db_mysql_convert_row: failed to
convert value
Jan  7 07:29:09 [10189] ERROR:core:db_do_insert: invalid parameter value
Jan  7 07:29:09 [10189] ERROR:pua:db_update: while inserting in db table
pua

Core was generated by `/usr/local/sbin/opensips -m 1024'.
Program terminated with signal 11, Segmentation fault.
#0  db_free_row (_r=0x81b79e8) at db/db_row.c:62
62                      switch (VAL_TYPE(_val)) {
(gdb) bt full
#0  db_free_row (_r=0x81b79e8) at db/db_row.c:62
        col = 0
        _val = (db_val_t *) 0x0
        __FUNCTION__ = "db_free_row"
#1  0xb7d9b580 in db_mysql_convert_row (_h=0x81b3820, _res=0x81ad938,
_r=0x81b79e8) at row.c:69
        lengths = (long unsigned int *) 0x481aebcc
        i = 135935876
        __FUNCTION__ = "db_mysql_convert_row"
#2  0xb7d9aeca in db_mysql_convert_result (_h=0x81b3820, _r=0x81ad938) at
res.c:171
        __FUNCTION__ = "db_mysql_convert_result"
#3  0xb7d98a2f in db_mysql_store_result (_h=0x81b3820, _r=0xbf9f4500) at
dbase.c:177
        __FUNCTION__ = "db_mysql_store_result"
#4  0x0811b94f in db_do_query (_h=0x81b3820, _k=0xbf9f44f4, _op=0x0,
_v=0xbf9f4474, _c=0xbf9f449c, _n=1, _nc=6, _o=0xb78e6834, _r=0xbf9f4500,
    val2str=0xb7d9b780 <db_mysql_val2str>, submit_query=0xb7d98de9
<db_mysql_submit_query>, store_result=0xb7d989c7 <db_mysql_store_result>)
    at db/db_query.c:105
        tmp = <value optimized out>
        off = 132
        ret = <value optimized out>
        __FUNCTION__ = "db_do_query"
#5  0xb7d97d05 in db_mysql_query (_h=0x81b3820, _k=0xbf9f44f4, _op=0x0,
_v=0xbf9f4474, _c=0xbf9f449c, _n=1, _nc=6, _o=0xb78e6834, _r=0xbf9f4500)
    at dbase.c:247
No locals.
#6  0xb78d4c75 in timer_send_notify (ticks=80, param=0x0) at
resource_notify.c:493
        query_cols = {0xb78e6844, 0x0}
        update_cols = {0xb78e6844}
        result_cols = {0xb78e6834, 0xb78e683c, 0xb78e684c, 0xb78e685c,
0xb78e6854, 0xb78e6864, 0x0}
        query_vals = {{type = DB_INT, nul = 0, free = 2007089048, val =
{int_val = 1, double_val = -2.766852607421637e-39, time_val = 1,
      string_val = 0x1 <Address 0x1 out of bounds>, str_val = {s = 0x1
<Address 0x1 out of bounds>, len = -1209130788}, blob_val = {
        s = 0x1 <Address 0x1 out of bounds>, len = -1209130788},
bitmap_val = 1}}, {type = 3085836512, nul = -1209131020, free = 310, val =
{int_val = 310,
      double_val = -0.03053575754165757, time_val = 310, string_val =
0x136 <Address 0x136 out of bounds>, str_val = {
        s = 0x136 <Address 0x136 out of bounds>, len = -1080081212},
blob_val = {s = 0x136 <Address 0x136 out of bounds>, len = -1080081212},
      bitmap_val = 310}}}
        update_vals = {{type = DB_DATETIME, nul = 2007089048, free =
-1080081152, val = {int_val = -1, double_val = -3.3348689399357007e-39,
time_val = -1,
      string_val = 0xffffffff <Address 0xffffffff out of bounds>, str_val
= {s = 0xffffffff <Address 0xffffffff out of bounds>, len = -1208866784},
      blob_val = {s = 0xffffffff <Address 0xffffffff out of bounds>, len =
-1208866784}, bitmap_val = 4294967295}}}
        i = <value optimized out>
        result = (db_res_t *) 0x81ad938
        prev_did = <value optimized out>
        curr_did = <value optimized out>
        row_vals = <value optimized out>
        resource_uri = <value optimized out>
        pres_state = <value optimized out>
        callid = {s = 0x0, len = 0}
        to_tag = {s = 0x481c67ed
"h\034H_h\034H`h\034H?k\034Hc3-2-80;210632768;97b57f2144c425bc44f2e7a21eb22549-f3e9",
len = 79}
        from_tag = {s = 0x481c67e4
"4h\034HHh\034HJh\034H_h\034H`h\034H?k\034Hc3-2-80;210632768;97b57f2144c425bc44f2e7a21eb22549-f3e9",
len = 8}
        rlmi_doc = <value optimized out>
        list_node = <value optimized out>
        instance_node = <value optimized out>
        resource_node = <value optimized out>
        hash_code = <value optimized out>
        size = <value optimized out>
        buf_len = <value optimized out>
        buf = <value optimized out>
        auth_state = <value optimized out>
        contor = <value optimized out>
        auth_state_flag = <value optimized out>
        bstr = {s = 0x0, len = 0}
---Type <return> to continue, or q <return> to quit---
        rlmi_cont = {s = 0x0, len = 0}
        multi_cont = {s = 0x0, len = 8}
        s = <value optimized out>
        dialog = <value optimized out>
        rl_uri = <value optimized out>
        str_aux = <value optimized out>
        __FUNCTION__ = "timer_send_notify"
#7  0x080ccfb5 in start_timer_processes () at timer.c:280
        tpl = (struct sr_timer_process *) 0x81acad8
        pid = <value optimized out>
        first = <value optimized out>
        __FUNCTION__ = "start_timer_processes"
#8  0x0806f189 in main (argc=3, argv=0xbf9f46b4) at main.c:666
        cfg_log_stderr = 0
        cfg_stream = (FILE *) 0x481a4008
        c = <value optimized out>
        r = <value optimized out>
        tmp = 0xbf9f5dec ""
        tmp_len = <value optimized out>
        port = <value optimized out>
        proto = <value optimized out>
        ret = <value optimized out>
        seed = 3089561270
        rfd = 4
        __FUNCTION__ = "main"
(gdb)



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

Comment By: Nathan (rmnathan)
Date: 2009-01-07 14:15

Message:
Hi
the full trace as follows 
 
Core was generated by `/usr/local/sbin/opensips'.
Program terminated with signal 11, Segmentation fault.
#0  0xb78e7eca in timer_send_notify (ticks=120, param=0x0) at
resource_notify.c:721
721                            
if(strncmp(row_vals[resource_uri_col].val.string_val,
(gdb) bt full
#0  0xb78e7eca in timer_send_notify (ticks=120, param=0x0) at
resource_notify.c:721
        query_cols = {0xb78f8844, 0xb7aab510}
        update_cols = {0x0}
        result_cols = {0xb78f8834, 0xb78f883c, 0xb78f884c, 0xb78f885c,
0xb78f8854, 0xb78f8864, 0x0}
        query_vals = {{type = DB_INT, nul = 0, free = -1247617128, val =
{int_val = 1, double_val = 4.2439915824246103e-314, time_val = 1,
      string_val = 0x1 <Address 0x1 out of bounds>, str_val = {s = 0x1
<Address 0x1 out of bounds>, len = 2}, blob_val = {
        s = 0x1 <Address 0x1 out of bounds>, len = 2}, bitmap_val = 1}},
{type = DB_DOUBLE, nul = 0, free = -1081894044, val = {int_val = 135974160,
      double_val = 6.7180161178120992e-316, time_val = 135974160,
string_val = 0x81acd10 "??????\032\b", str_val = {s = 0x81acd10
"??????\032\b", len = 0},
      blob_val = {s = 0x81acd10 "??????\032\b", len = 0}, bitmap_val
= 135974160}}}
        update_vals = {{type = DB_DATETIME, nul = -1247617128, free =
-1243838944, val = {int_val = -1213549416, double_val =
-1.5328670054899573e-40,
      time_val = -1213549416, string_val = 0xb7aab498 "?S??\006",
str_val = {s = 0xb7aab498 "?S??\006", len = -1213549360}, blob_val = {
        s = 0xb7aab498 "?S??\006", len = -1213549360}, bitmap_val =
3081417880}}}
        i = 298
        result = (db_res_t *) 0x828f678
        prev_did = 0x4821159c
"s6-13-80;100595200;97b57f2144c425bc44f2e7a21eb22549-1265"
        curr_did = 0x48211d5c
"s6-14-80;218035712;97b57f2144c425bc44f2e7a21eb22549-365a"
        row_vals = (db_val_t *) 0x64697072
        resource_uri = <value optimized out>
        pres_state = 0x48211dc2 "<?xml version=\"1.0\"
encoding=\"UTF-8\"?>\n<presence xmlns=\"urn:ietf:params:xml:ns:pidf\"
xmlns:rpid=\"urn:ietf:params:xml:ns:pidf:rpid\"
xmlns:dm=\"urn:ietf:params:xml:ns:pidf:data-model\"
xmlns:pcp=\"urn:ietf"...
        callid = {s = 0x48211d5c
"s6-14-80;218035712;97b57f2144c425bc44f2e7a21eb22549-365a", len = 8}
        to_tag = {s = 0x48211d6f "97b57f2144c425bc44f2e7a21eb22549-365a",
len = 37}
        from_tag = {s = 0x48211d65
"218035712;97b57f2144c425bc44f2e7a21eb22549-365a", len = 9}
        rlmi_doc = (xmlDocPtr) 0x481aec20
        list_node = (xmlNodePtr) 0x481accb8
        instance_node = (xmlNodePtr) 0x481f0da0
        resource_node = (xmlNodePtr) 0x481af8c0
        hash_code = 349
        size = 6144
        buf_len = 1007
        buf = 0x8298040
"--uiJUnfDUyfcSFWRINqnYyVEx\r\n\r\nContent-Transfer-Encoding:
binary\r\nContent-ID:
<1231322726.sip:c6-18 at 10.6.2.246.596516649>\r\nContent-Type:
application/pidf+xml\r\n\r\n<?xml version=\"1.0\"
encoding=\"UTF-8\"?>\n<"...
        auth_state = <value optimized out>
        contor = 1
        auth_state_flag = <value optimized out>
        bstr = {s = 0x8292c30 "uiJUnfDUyfcSFWRINqnYyVEx", len = 24}
        rlmi_cont = {
  s = 0x481f0fd8 "pT??pT???\017\037H?\017\037H.0\"?>\n<list
uri=\"sip:s6-13 at 10.6.2.246\" xmlns=\"urn:ietf:params:xml:ns:rlmi\"
version=\"2\" fullState=\"false\">\n  <resource
uri=\"sip:c6-17 at 10.6.2.246\">\n    <instance id=\"icDW4oK5\"
state=\"act"..., len = 959}
        multi_cont = {
  s = 0x8298040
"--uiJUnfDUyfcSFWRINqnYyVEx\r\n\r\nContent-Transfer-Encoding:
binary\r\nContent-ID:
<1231322726.sip:c6-18 at 10.6.2.246.596516649>\r\nContent-Type:
application/pidf+xml\r\n\r\n<?xml version=\"1.0\"
encoding=\"UTF-8\"?>\n<"..., len = 6053}
        s = (subs_t *) 0xb602c300
        dialog = (subs_t *) 0x81a7ef0
        rl_uri = 0x8291670 "sip:s6-14 at 10.6.2.246"
        str_aux = <value optimized out>
        __FUNCTION__ = "timer_send_notify"
#1  0x080ccfb5 in start_timer_processes () at timer.c:280
        tpl = (struct sr_timer_process *) 0x81acad8
        pid = <value optimized out>
        first = <value optimized out>
        __FUNCTION__ = "start_timer_processes"
#2  0x0806f189 in main (argc=1, argv=0xbf839d14) at main.c:666
        cfg_log_stderr = 0
        cfg_stream = (FILE *) 0x481a4008
        c = <value optimized out>
        r = <value optimized out>
---Type <return> to continue, or q <return> to quit---
        tmp = 0x8166200 "\034a\026\bhF??@???"
        tmp_len = <value optimized out>
        port = <value optimized out>
        proto = <value optimized out>
        ret = <value optimized out>
        seed = 82752229
        rfd = 4
        __FUNCTION__ = "main"
(gdb)

Regards,
rmnathan

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

Comment By: Nobody/Anonymous (nobody)
Date: 2009-01-07 13:04

Message:
It would help to provide the backtrace with the full context and the value
of the local variables. To do that use "bt full" instead of just "bt".

Dan


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

Comment By: Nathan (rmnathan)
Date: 2009-01-07 12:40

Message:
Hi Anca,
I observed few crashes as follows while testing with new trunck build.

Crash 1:
======
Core was generated by `/usr/local/sbin/opensips -m 1024'.
Program terminated with signal 11, Segmentation fault.
#0  0xb7e18d00 in strncmp () from /lib/libc.so.6
(gdb) bt
#0  0xb7e18d00 in strncmp () from /lib/libc.so.6
#1  0xb78cfee3 in timer_send_notify (ticks=40, param=0x0) at
resource_notify.c:721
#2  0x080ccfb5 in start_timer_processes () at timer.c:280
#3  0x0806f189 in main (argc=3, argv=0xbfb57014) at main.c:666

Crash 2:
======
Program terminated with signal 11, Segmentation fault.
#0  fm_malloc (qm=0x81a3ba0, size=2640) at mem/f_malloc.c:267
267                             if ((*f)->size>=size) goto found;
(gdb) bt
#0  fm_malloc (qm=0x81a3ba0, size=2640) at mem/f_malloc.c:267
#1  0xb78dcb51 in agg_body_sendn_update (rl_uri=0x81a7ef0,
boundary_string={s = 0x81dadc0 "j5dDEBAL5H1LAtor2qUGI2ac", len = 24},
rlmi_body=0xbfef61d4,
    multipart_body=0xbfef61cc, subs=0x81a7ef0, hash_code=1978) at
notify.c:238
#2  0xb78dfefe in timer_send_notify (ticks=60, param=0x0) at
resource_notify.c:544
#3  0x080ccfb5 in start_timer_processes () at timer.c:280
#4  0x0806f189 in main (argc=3, argv=0xbfef63b4) at main.c:666

crash 3:
======
#0  0xb78e7eca in timer_send_notify (ticks=120, param=0x0) at
resource_notify.c:721
721                            
if(strncmp(row_vals[resource_uri_col].val.string_val,
(gdb) bt
#0  0xb78e7eca in timer_send_notify (ticks=120, param=0x0) at
resource_notify.c:721
#1  0x080ccfb5 in start_timer_processes () at timer.c:280
#2  0x0806f189 in main (argc=1, argv=0xbf839d14) at main.c:666

crash 4:
======
Core was generated by `/usr/local/sbin/opensips -m 1024'.
Program terminated with signal 11, Segmentation fault.
#0  db_free_row (_r=0x81c25d0) at db/db_row.c:62
62                      switch (VAL_TYPE(_val)) {

crash 5:
======
Core was generated by `/usr/local/sbin/opensips'.
Program terminated with signal 11, Segmentation fault.
#0  0x080f9282 in parse_uri (buf=0x8 <Address 0x8 out of bounds>,
len=135995841, uri=0xbf9fbfe0) at parser/parse_uri.c:329
329             scheme=buf[0]+(buf[1]<<8)+(buf[2]<<16)+(buf[3]<<24);


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

Comment By: Anca Vamanu (anca_vamanu)
Date: 2009-01-06 16:41

Message:
Hi Meganathan,

I think that I have finally found the bug this time. Can you please
update, test again and confirm?

Thanks and regards,
Anca

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

Comment By: Nathan (rmnathan)
Date: 2008-12-31 11:37

Message:
Hi Anca,
 Any update on this issue?

Regards,
Meganathan.

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

Comment By: Nathan (rmnathan)
Date: 2008-12-18 16:45

Message:
Hi Anca 
 I have retested with latest build (rev 5071). Again I got the crash  

(gdb) bt
#0  0xb7e1861d in _IO_str_overflow () from /lib/libc.so.6
#1  0xb7e17747 in _IO_default_xsputn () from /lib/libc.so.6
#2  0xb7deea94 in vfprintf () from /lib/libc.so.6
#3  0xb7e0c92c in vsprintf () from /lib/libc.so.6
#4  0xb7df775e in sprintf () from /lib/libc.so.6
#5  0xb78d810b in timer_send_notify (ticks=40, param=0x0) at
resource_notify.c:700
#6  0x080ccb55 in start_timer_processes () at timer.c:280
#7  0x0806ef69 in main (argc=1, argv=0xbfa78f44) at main.c:666

Regards,
rmnathan


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

Comment By: Anca Vamanu (anca_vamanu)
Date: 2008-12-18 14:28

Message:
Hi rmnathan,

I have made some changes in the rls module. 
Can you please update and test again?

regards,
Anca

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

Comment By: Nathan (rmnathan)
Date: 2008-12-16 12:12

Message:
Hi Anca,
After i compiled with following commands i got core dump with line
numbers.

make
echo $?
make prefix=/usr/local/ install

Program terminated with signal 11, Segmentation fault.
#0  0xb7e5161d in _IO_str_overflow () from /lib/libc.so.6
(gdb) bt
#0  0xb7e5161d in _IO_str_overflow () from /lib/libc.so.6
#1  0xb7e50747 in _IO_default_xsputn () from /lib/libc.so.6
#2  0xb7e27a94 in vfprintf () from /lib/libc.so.6
#3  0xb7e4592c in vsprintf () from /lib/libc.so.6
#4  0xb7e3075e in sprintf () from /lib/libc.so.6
#5  0xb7911d53 in timer_send_notify (ticks=40, param=0x0) at
resource_notify.c:687
#6  0x080ccb55 in start_timer_processes () at timer.c:280
#7  0x0806ef69 in main (argc=1, argv=0xbf805cf4) at main.c:666

regards,
rmnathan


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

Comment By: Nathan (rmnathan)
Date: 2008-12-16 11:45

Message:
Hi Anca,
I have tried with latest trunk build (rev 5060), am getting the same
crash.
I have set 'ulimit -c unlimited' also but the line numbers not getting
printed.

Core was generated by `opensips'.
Program terminated with signal 11, Segmentation fault.
#0  0xb7ec161d in _IO_str_overflow () from /lib/libc.so.6
(gdb) bt
#0  0xb7ec161d in _IO_str_overflow () from /lib/libc.so.6
#1  0xb7ec0747 in _IO_default_xsputn () from /lib/libc.so.6
#2  0xb7e97a94 in vfprintf () from /lib/libc.so.6
#3  0xb7eb592c in vsprintf () from /lib/libc.so.6
#4  0xb7ea075e in sprintf () from /lib/libc.so.6
#5  0xb799a25d in timer_send_notify () from
/usr/local//lib/opensips/modules/rls.so
#6  0x080b1194 in timer_ticker ()
#7  0x080b0fc5 in run_timer_process ()
#8  0x080b12ff in start_timer_processes ()
#9  0x08065cdd in main_loop ()
#10 0x08067f53 in main ()

Regards
rmnathan

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

Comment By: Anca Vamanu (anca_vamanu)
Date: 2008-12-15 16:19

Message:
Hi rmnathan,

I have tested myself and got a crash after some time - it was due to a
recent change that I made. I have commited the fix in trunk.
However I am not really sure it is the same as you have seen, as in your
trace there isn't enough information -like line numbers. Can you please
update and test again and report if you see the crash again. 
Btw, have you run: 'ulimit -c unlimited'?

regards,
Anca 


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

Comment By: Nathan (rmnathan)
Date: 2008-12-15 13:17

Message:
Finally core has created. Please see below

stinbng46:/# gdb /usr/local/sbin/opensips core
GNU gdb 6.4.90-debian
Copyright (C) 2006 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you
are
welcome to change it and/or distribute copies of it under certain
conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for
details.
This GDB was configured as "i486-linux-gnu"...Using host libthread_db
library "/lib/libthread_db.so.1".


warning: Can't read pathname for load map: Input/output error.
Reading symbols from /lib/libdl.so.2...done.
Loaded symbols for /lib/libdl.so.2
Reading symbols from /lib/libresolv.so.2...done.
Loaded symbols for /lib/libresolv.so.2
Reading symbols from /lib/libc.so.6...done.
Loaded symbols for /lib/libc.so.6
Reading symbols from /lib/ld-linux.so.2...done.
Loaded symbols for /lib/ld-linux.so.2
Reading symbols from /usr/local/lib/opensips/modules/db_mysql.so...done.
Loaded symbols for /usr/local//lib/opensips/modules/db_mysql.so
Reading symbols from /usr/lib/libmysqlclient.so.15...done.
Loaded symbols for /usr/lib/libmysqlclient.so.15
Reading symbols from /lib/libpthread.so.0...done.
Loaded symbols for /lib/libpthread.so.0
Reading symbols from /lib/libcrypt.so.1...done.
Loaded symbols for /lib/libcrypt.so.1
Reading symbols from /lib/libnsl.so.1...done.
Loaded symbols for /lib/libnsl.so.1
Reading symbols from /lib/libm.so.6...done.
Loaded symbols for /lib/libm.so.6
Reading symbols from /usr/lib/libz.so.1...done.
Loaded symbols for /usr/lib/libz.so.1
Reading symbols from /usr/local/lib/opensips/modules/sl.so...done.
Loaded symbols for /usr/local//lib/opensips/modules/sl.so
Reading symbols from /usr/local/lib/opensips/modules/maxfwd.so...done.
Loaded symbols for /usr/local//lib/opensips/modules/maxfwd.so
Reading symbols from /usr/local/lib/opensips/modules/textops.so...done.
Loaded symbols for /usr/local//lib/opensips/modules/textops.so
Reading symbols from /usr/local/lib/opensips/modules/tm.so...done.
Loaded symbols for /usr/local//lib/opensips/modules/tm.so
Reading symbols from /usr/local/lib/opensips/modules/rr.so...done.
Loaded symbols for /usr/local//lib/opensips/modules/rr.so
Reading symbols from /usr/local/lib/opensips/modules/presence.so...done.
Loaded symbols for /usr/local//lib/opensips/modules/presence.so
Reading symbols from /usr/lib/libxml2.so.2...done.
Loaded symbols for /usr/lib/libxml2.so.2
Reading symbols from /usr/local/lib/opensips/modules/avpops.so...done.
Loaded symbols for /usr/local//lib/opensips/modules/avpops.so
Reading symbols from /usr/local/lib/opensips/modules/pua.so...done.
Loaded symbols for /usr/local//lib/opensips/modules/pua.so
Reading symbols from /usr/local/lib/opensips/modules/mi_fifo.so...done.
Loaded symbols for /usr/local//lib/opensips/modules/mi_fifo.so
Reading symbols from
/usr/local/lib/opensips/modules/presence_xml.so...done.
Loaded symbols for /usr/local//lib/opensips/modules/presence_xml.so
Reading symbols from /usr/local/lib/opensips/modules/rls.so...done.
Loaded symbols for /usr/local//lib/opensips/modules/rls.so
Reading symbols from /usr/local/lib/opensips/modules/xlog.so...done.
Loaded symbols for /usr/local//lib/opensips/modules/xlog.so
Reading symbols from /usr/local/lib/opensips/modules/signaling.so...done.
Loaded symbols for /usr/local//lib/opensips/modules/signaling.so
Reading symbols from /lib/libnss_db.so.2...done.
Loaded symbols for /lib/libnss_db.so.2
Reading symbols from /lib/libnss_files.so.2...done.
Loaded symbols for /lib/libnss_files.so.2
Reading symbols from /usr/lib/libdb3.so.3...done.
Loaded symbols for /usr/lib/libdb3.so.3
Core was generated by `/usr/local/sbin/opensips -D'.
Program terminated with signal 11, Segmentation fault.
#0  0xb7e9f61d in _IO_str_overflow () from /lib/libc.so.6
(gdb) bt
#0  0xb7e9f61d in _IO_str_overflow () from /lib/libc.so.6
#1  0xb7e9e747 in _IO_default_xsputn () from /lib/libc.so.6
#2  0xb7e75a94 in vfprintf () from /lib/libc.so.6
#3  0xb7e9392c in vsprintf () from /lib/libc.so.6
#4  0xb7e7e75e in sprintf () from /lib/libc.so.6
#5  0xb7978256 in timer_send_notify () from
/usr/local//lib/opensips/modules/rls.so
#6  0x080b11a0 in timer_ticker ()
#7  0x080b0fd1 in run_timer_process ()
#8  0x080b130b in start_timer_processes ()
#9  0x08065cdd in main_loop ()
#10 0x08067f5f in main ()

Regards
rmnathan


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

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


From noreply at sourceforge.net  Thu Feb 19 13:08:05 2009
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 19 Feb 2009 12:08:05 +0000
Subject: [OpenSIPS-Devel] [ opensips-Bugs-2391787 ] Error in sending NOTIFY
	for refresh SUBSCRIBE in RLS module
Message-ID: <E1La7hF-0003CM-Sr@d45xhf1.ch3.sourceforge.com>

Bugs item #2391787, was opened at 2008-12-05 08:03
Message generated for change (Comment added) made by anca_vamanu
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=2391787&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: Wont Fix
Priority: 9
Private: No
Submitted By: Nathan (rmnathan)
Assigned to: Anca Vamanu (anca_vamanu)
Summary: Error in sending NOTIFY for refresh SUBSCRIBE in RLS module

Initial Comment:
Version = trunk build
Module = RLS


The NOTIFY msg for refresh subscribe is sending directly to UE instead of sending to proxy in RLS mode. In that Route header is missing.

Initial subscribe 
==================
1. Proxy to opensips

SUBSCRIBE sip:s3-1 at 10.6.2.246 SIP/2.0
Via: SIP/2.0/UDP 192.168.126.1:50602;branch=z9hG4bK+bf0d90f7f3edfa41d338960687825df3+s+1;X-ST-CID=21011
Via: SIP/2.0/UDP 192.168.126.151:60000;branch=z9hG4bK-s3-114461640680
P-Charging-Vector: icid-value=starent.coms3-1-80
Route: <sip:10.6.2.246:5060;lr>
Expires: 200
Event: presence
Accept: application/rlmi+xml
Accept: multipart/related
Accept: application/pidf+xml
Supported: eventlist
From: sip:s3-1 at 10.6.2.246;tag=59572288
To: sip:s3-1 at 10.6.2.246
P-Asserted-Identity: <sip:s3-1 at 10.6.2.246>
Record-Route: <sip:192.168.126.1:50602;lr>;X-DC-TM-IDX=1;X-ST-CID=21011
Record-Route: <sip:192.168.126.1:50602;lr>;X-DC-TM-IDX=1;X-ST-CID=20002;X-ST-DLG-ID=536870913
Call-ID: s3-1-80
CSeq: 1 SUBSCRIBE
Contact: <sip:s3-1 at 192.168.126.151:60000>
Content-Length: 0
Max-Forwards: 69

2. Notify for initial subscribe (opensips to proxy)

NOTIFY sip:s3-1 at 192.168.126.151:60000 SIP/2.0
Via: SIP/2.0/UDP 10.6.2.246;branch=z9hG4bKaa48.106098f2.0
To: sip:s3-1 at 10.6.2.246;tag=59572288
From: sip:s3-1 at 10.6.2.246;tag=97b57f2144c425bc44f2e7a21eb22549-b818
CSeq: 1 NOTIFY
Call-ID: s3-1-80
Route: <sip:192.168.126.1:50602;lr>;X-DC-TM-IDX=1;X-ST-CID=21011,
       <sip:192.168.126.1:50602;lr>;X-DC-TM-IDX=1;X-ST-CID=20002;X-ST-DLG-ID=536870913
Content-Length: 375
User-Agent: OpenSIPS (1.5.0dev2-notls (i386/linux))
Max-Forwards: 70
Event: presence
Contact: <sip:10.6.2.246:5060;transport=udp>
Subscription-State: active;expires=200
Require: eventlist
Content-Type: multipart/related;type="application/rlmi+xml";start= "<1228453070.sip:s3-1 at 10.6.2.246.1463319679>";boundary="Fk3QCGTvdTGnGmVrrm5wBXef"

--Fk3QCGTvdTGnGmVrrm5wBXef
Content-Transfer-Encoding: binary
Content-ID: <1228453070.sip:s3-1 at 10.6.2.246.1463319679>
Content-Type: application/rlmi+xml;charset="UTF-8r"

<?xml version="1.0"?>
<list uri="sip:s3-1 at 10.6.2.246" xmlns="urn:ietf:params:xml:ns:rlmi" version="1" fullState="true">
  <resource uri="sip:c3-1 at 10.6.2.246"/>
</list>

--Fk3QCGTvdTGnGmVrrm5wBXef--


Refresh Subscribe 
===================
1. Proxy to opensips

SUBSCRIBE sip:10.6.2.246:5060 SIP/2.0
Via: SIP/2.0/UDP 192.168.126.1:50602;branch=z9hG4bK+bd987cb1d4b434a184c0ad66fe527ebc+s+1;X-ST-CID=21013
Via: SIP/2.0/UDP 192.168.126.151:60000;branch=z9hG4bK-s3-114224888240
P-Charging-Vector: icid-value=starent.coms3-1-80
Expires: 200
Event: presence
Accept: application/rlmi+xml
Accept: multipart/related
Accept: application/pidf+xml
Supported: eventlist
From: sip:s3-1 at 10.6.2.246;tag=59572288
To: sip:s3-1 at 10.6.2.246;tag=97b57f2144c425bc44f2e7a21eb22549-b818
P-Asserted-Identity: <sip:s3-1 at 10.6.2.246>
Call-ID: s3-1-80
CSeq: 2 SUBSCRIBE
Contact: <sip:s3-1 at 192.168.126.151:60000>
Content-Length: 0
Max-Forwards: 69

2. Notify for Refresh subscribe (opensips to proxy)

Issue:
=====
Here Notification is sending directly to UE. No route header has added. 
Opensips should send to proxy.
Finally lot of re transmission happened for NOTIFY (for not getting 200 ok )

Dec  4 23:58:11 [26262] DBG:tm:utimer_routine: timer routine:4,tl=0xb5b012fc next=0xb5afbefc, timeout=46500000
Dec  4 23:58:11 [26262] DBG:tm:retransmission_handler: retransmission_handler : request resending (t=0xb5b011a0, NOTIFY si ... )
Dec  4 23:58:11 [26262] DBG:tm:set_timer: relative timeout is 1000000
Dec  4 23:58:11 [26262] DBG:tm:insert_timer_unsafe: [5]: 0xb5b012fc (47500000)
Dec  4 23:58:11 [26262] DBG:tm:retransmission_handler: retransmission_handler : done
Dec  4 23:58:11 [26262] DBG:tm:utimer_routine: timer routine:4,tl=0xb5afbefc next=(nil), timeout=46500000
Dec  4 23:58:11 [26262] DBG:tm:utimer_routine: timer routine:4,tl=0xb5afe5ec next=(nil), timeout=46600000
Dec  4 23:58:12 [26262] DBG:tm:utimer_routine: timer routine:5,tl=0xb5b012fc next=(nil), timeout=47500000
Dec  4 23:58:12 [26262] DBG:tm:retransmission_handler: retransmission_handler : request resending (t=0xb5b011a0, NOTIFY si ... )
Dec  4 23:58:12 [26262] DBG:tm:set_timer: relative timeout is 2000000
Dec  4 23:58:12 [26262] DBG:tm:insert_timer_unsafe: [6]: 0xb5b012fc (49500000)
Dec  4 23:58:12 [26262] DBG:tm:retransmission_handler: retransmission_handler : done
Dec  4 23:58:14 [26262] DBG:tm:utimer_routine: timer routine:6,tl=0xb5b012fc next=(nil), timeout=49500000
Dec  4 23:58:14 [26262] DBG:tm:retransmission_handler: retransmission_handler : request resending (t=0xb5b011a0, NOTIFY si ... )
Dec  4 23:58:14 [26262] DBG:tm:set_timer: relative timeout is 4000000
Dec  4 23:58:14 [26262] DBG:tm:insert_timer_unsafe: [7]: 0xb5b012fc (53500000)
Dec  4 23:58:14 [26262] DBG:tm:retransmission_handler: retransmission_handler : done

NOTIFY sip:s3-1 at 192.168.126.151:60000 SIP/2.0^M
Via: SIP/2.0/UDP 10.6.2.246;branch=z9hG4bK7a48.974c01c7.0^M
To: sip:s3-1 at 10.6.2.246;tag=59572288^M
From: sip:s3-1 at 10.6.2.246;tag=97b57f2144c425bc44f2e7a21eb22549-b818^M
CSeq: 2 NOTIFY^M
Call-ID: s3-1-80^M
Content-Length: 375^M
User-Agent: OpenSIPS (1.5.0dev2-notls (i386/linux))^M
Max-Forwards: 70^M
Event: presence^M
Contact: <sip:10.6.2.246:5060;transport=udp>^M
Subscription-State: active;expires=200^M
Require: eventlist^M
Content-Type: multipart/related;type="application/rlmi+xml";start= "<1228453091.sip:s3-1 at 10.6.2.246.1092908929>";boundary="ysnG2GAKNcGvKOj5Zeqlnwvx"^M
^M
--ysnG2GAKNcGvKOj5Zeqlnwvx^M
Content-Transfer-Encoding: binary^M
Content-ID: <1228453091.sip:s3-1 at 10.6.2.246.1092908929>^M
Content-Type: application/rlmi+xml;charset="UTF-8r"^M
^M
<?xml version="1.0"?>
<list uri="sip:s3-1 at 10.6.2.246" xmlns="urn:ietf:params:xml:ns:rlmi" version="2" fullState="true">
  <resource uri="sip:c3-1 at 10.6.2.246"/>
</list>
^M
--ysnG2GAKNcGvKOj5Zeqlnwvx--

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

>Comment By: Anca Vamanu (anca_vamanu)
Date: 2009-02-19 14:08

Message:
Hi Rmnathan,
 
Can you please give an update report on this issue - test again and see if
it works for you. I would like to close this bug report.

regards,
Anca

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

Comment By: Anca Vamanu (anca_vamanu)
Date: 2008-12-10 13:57

Message:
Hi rmnathan,

I don't know why it is not working for you. Are you sure you have
recompiled and installed the new version?
Here is what I get with latest trunk ( I have my rls sever on 5070 and my
proxy on 5060):

Initial Subscribe and Notify:
U 2008/12/10 12:42:50.302010 192.168.2.132:5060 -> 192.168.2.132:5070
SUBSCRIBE sip:anca-list at 192.168.2.132 SIP/2.0.
Record-Route:
<sip:192.168.2.132;lr=on;ftag=tYhh7SHJRR395OUzDiZ6Jj7DkqbiqFtS>.
Via: SIP/2.0/UDP 192.168.2.132;branch=z9hG4bK4aef.9de66b4.0.
Via: SIP/2.0/UDP
192.168.2.132:60798;received=192.168.2.132;rport=60798;branch=z9hG4bKPjx-ZFVEz72zPCBm.26QfUJrE5.8cILj-I.
Max-Forwards: 69.
From: <sip:anca at 192.168.2.132>;tag=tYhh7SHJRR395OUzDiZ6Jj7DkqbiqFtS.
To: <sip:anca-list at 192.168.2.132>.
Contact: <sip:0fbeacc898 at 192.168.2.132:60798>.
Call-ID: .ei4OvgfjW1xdrwO5vof0wuZSctcMx7o.
CSeq: 3606 SUBSCRIBE.
Event: presence.
Expires: 300.
Accept: multipart/related.
Allow-Events: presence.winfo, message-summary, xcap-diff, presence.
User-Agent: ag-projects/sipclient-0.2.3-pjsip-1.0-trunk.
Supported: eventlist.
Content-Length:  0.
.


U 2008/12/10 12:42:50.303408 192.168.2.132:5070 -> 192.168.2.132:5060
SIP/2.0 200 OK.
Record-Route:
<sip:192.168.2.132;lr=on;ftag=tYhh7SHJRR395OUzDiZ6Jj7DkqbiqFtS>.
Via: SIP/2.0/UDP 192.168.2.132;branch=z9hG4bK4aef.9de66b4.0.
Via: SIP/2.0/UDP
192.168.2.132:60798;received=192.168.2.132;rport=60798;branch=z9hG4bKPjx-ZFVEz72zPCBm.26QfUJrE5.8cILj-I.
From: <sip:anca at 192.168.2.132>;tag=tYhh7SHJRR395OUzDiZ6Jj7DkqbiqFtS.
To:
<sip:anca-list at 192.168.2.132>;tag=bbf7d4ee170841f97da4789c46f9e5df-6231.
Call-ID: .ei4OvgfjW1xdrwO5vof0wuZSctcMx7o.
CSeq: 3606 SUBSCRIBE.
Expires: 300.
Contact: <sip:sa at 192.168.2.132:5070>.
Require: eventlist.
Server: OpenSIPS (1.5.0dev2-notls (i386/linux)).
Content-Length: 0.
.


U 2008/12/10 12:42:50.304922 192.168.2.132:5070 -> 192.168.2.132:5060
NOTIFY sip:0fbeacc898 at 192.168.2.132:60798 SIP/2.0.
Via: SIP/2.0/UDP 192.168.2.132:5070;branch=z9hG4bKa93b.6404ecb1.0.
To: sip:anca at 192.168.2.132;tag=tYhh7SHJRR395OUzDiZ6Jj7DkqbiqFtS.
From:
sip:anca-list at 192.168.2.132;tag=bbf7d4ee170841f97da4789c46f9e5df-6231.
CSeq: 1 NOTIFY.
Call-ID: .ei4OvgfjW1xdrwO5vof0wuZSctcMx7o.
Route: <sip:192.168.2.132;lr=on;ftag=tYhh7SHJRR395OUzDiZ6Jj7DkqbiqFtS>.
Content-Length: 437.
User-Agent: OpenSIPS (1.5.0dev2-notls (i386/linux)).
Max-Forwards: 70.
Event: presence.
Contact: <sip:sa at 192.168.2.132:5070>.
Subscription-State: active;expires=300.
Require: eventlist.
Content-Type: multipart/related;type="application/rlmi+xml";start=
"<1228905770.sip:anca-list at 192.168.2.132.1388638956>";boundary="HXViZAnDGnx6WEgIVJqjZtAK".
.
--HXViZAnDGnx6WEgIVJqjZtAK.
Content-Transfer-Encoding: binary.
Content-ID: <1228905770.sip:anca-list at 192.168.2.132.1388638956>.
Content-Type: application/rlmi+xml;charset="UTF-8r".
.
<?xml version="1.0"?>
<list uri="sip:anca-list at 192.168.2.132"
xmlns="urn:ietf:params:xml:ns:rlmi" version="1" fullState="true">
  <resource uri="sip:anca at 192.168.2.132"/>
  <resource uri="sip:test at 192.168.2.132"/>
</list>
.
--HXViZAnDGnx6WEgIVJqjZtAK--.


U 2008/12/10 12:42:50.318589 192.168.2.132:5060 -> 192.168.2.132:5070
SIP/2.0 200 OK.
Via: SIP/2.0/UDP 192.168.2.132:5070;branch=z9hG4bKa93b.6404ecb1.0.
Call-ID: .ei4OvgfjW1xdrwO5vof0wuZSctcMx7o.
From:
<sip:anca-list at 192.168.2.132>;tag=bbf7d4ee170841f97da4789c46f9e5df-6231.
To: <sip:anca at 192.168.2.132>;tag=tYhh7SHJRR395OUzDiZ6Jj7DkqbiqFtS.
CSeq: 1 NOTIFY.
Contact: <sip:0fbeacc898 at 192.168.2.132:60798>.
Allow: SUBSCRIBE, NOTIFY, PRACK, INVITE, ACK, BYE, CANCEL, UPDATE,
MESSAGE.
Supported: 100rel.
Content-Length:  0.

Subsequent Subscribe and Notify:

U 2008/12/10 12:43:02.763386 192.168.2.132:5060 -> 192.168.2.132:5070
SUBSCRIBE sip:sa at 192.168.2.132:5070 SIP/2.0.
Via: SIP/2.0/UDP 192.168.2.132;branch=z9hG4bK5aef.08b10387.0.
Via: SIP/2.0/UDP
192.168.2.132:60798;received=192.168.2.132;rport=60798;branch=z9hG4bKPjpl9dFS5GA9NIY.dZASYV2yYZr4Nu2Mn2.
Max-Forwards: 69.
From: <sip:anca at 192.168.2.132>;tag=tYhh7SHJRR395OUzDiZ6Jj7DkqbiqFtS.
To:
<sip:anca-list at 192.168.2.132>;tag=bbf7d4ee170841f97da4789c46f9e5df-6231.
Contact: <sip:0fbeacc898 at 192.168.2.132:60798>.
Call-ID: .ei4OvgfjW1xdrwO5vof0wuZSctcMx7o.
CSeq: 3607 SUBSCRIBE.
Event: presence.
Expires: 0.
Accept: multipart/related.
Allow-Events: presence.winfo, message-summary, xcap-diff, presence.
User-Agent: ag-projects/sipclient-0.2.3-pjsip-1.0-trunk.
Supported: eventlist.
Content-Length:  0.
P-hint: rr-enforced.
.


U 2008/12/10 12:43:02.764563 192.168.2.132:5070 -> 192.168.2.132:5060
SIP/2.0 200 OK.
Via: SIP/2.0/UDP 192.168.2.132;branch=z9hG4bK5aef.08b10387.0.
Via: SIP/2.0/UDP
192.168.2.132:60798;received=192.168.2.132;rport=60798;branch=z9hG4bKPjpl9dFS5GA9NIY.dZASYV2yYZr4Nu2Mn2.
From: <sip:anca at 192.168.2.132>;tag=tYhh7SHJRR395OUzDiZ6Jj7DkqbiqFtS.
To:
<sip:anca-list at 192.168.2.132>;tag=bbf7d4ee170841f97da4789c46f9e5df-6231.
Call-ID: .ei4OvgfjW1xdrwO5vof0wuZSctcMx7o.
CSeq: 3607 SUBSCRIBE.
Expires: 0.
Contact: <sip:sa at 192.168.2.132:5070>.
Require: eventlist.
Server: OpenSIPS (1.5.0dev2-notls (i386/linux)).
Content-Length: 0.
.


U 2008/12/10 12:43:02.765773 192.168.2.132:5070 -> 192.168.2.132:5060
NOTIFY sip:0fbeacc898 at 192.168.2.132:60798 SIP/2.0.
Via: SIP/2.0/UDP 192.168.2.132:5070;branch=z9hG4bK793b.a3db3e03.0.
To: sip:anca at 192.168.2.132;tag=tYhh7SHJRR395OUzDiZ6Jj7DkqbiqFtS.
From:
sip:anca-list at 192.168.2.132;tag=bbf7d4ee170841f97da4789c46f9e5df-6231.
CSeq: 2 NOTIFY.
Call-ID: .ei4OvgfjW1xdrwO5vof0wuZSctcMx7o.
Route: <sip:192.168.2.132;lr=on;ftag=tYhh7SHJRR395OUzDiZ6Jj7DkqbiqFtS>.
Content-Length: 437.
User-Agent: OpenSIPS (1.5.0dev2-notls (i386/linux)).
Max-Forwards: 70.
Event: presence.
Contact: <sip:sa at 192.168.2.132:5070>.
Subscription-State: terminated;reason=timeout.
Require: eventlist.
Content-Type: multipart/related;type="application/rlmi+xml";start=
"<1228905782.sip:anca-list at 192.168.2.132.1973250666>";boundary="EnFWYBCacVbNJvhpjk6JakMf".
.
--EnFWYBCacVbNJvhpjk6JakMf.
Content-Transfer-Encoding: binary.
Content-ID: <1228905782.sip:anca-list at 192.168.2.132.1973250666>.
Content-Type: application/rlmi+xml;charset="UTF-8r".
.
<?xml version="1.0"?>
<list uri="sip:anca-list at 192.168.2.132"
xmlns="urn:ietf:params:xml:ns:rlmi" version="2" fullState="true">
  <resource uri="sip:anca at 192.168.2.132"/>
  <resource uri="sip:test at 192.168.2.132"/>
</list>
.
--EnFWYBCacVbNJvhpjk6JakMf--.

U 2008/12/10 12:43:02.774232 192.168.2.132:5060 -> 192.168.2.132:5070
SIP/2.0 200 OK.
Via: SIP/2.0/UDP 192.168.2.132:5070;branch=z9hG4bK793b.a3db3e03.0.
Call-ID: .ei4OvgfjW1xdrwO5vof0wuZSctcMx7o.
From:
<sip:anca-list at 192.168.2.132>;tag=bbf7d4ee170841f97da4789c46f9e5df-6231.
To: <sip:anca at 192.168.2.132>;tag=tYhh7SHJRR395OUzDiZ6Jj7DkqbiqFtS.
CSeq: 2 NOTIFY.
Contact: <sip:0fbeacc898 at 192.168.2.132:60798>.
Allow: SUBSCRIBE, NOTIFY, PRACK, INVITE, ACK, BYE, CANCEL, UPDATE,
MESSAGE.
Supported: 100rel.
Content-Length:  0.
.

regards,

Anca


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

Comment By: Anca Vamanu (anca_vamanu)
Date: 2008-12-10 13:28

Message:
Hi rmnathan,

I don't know why it is not working for you. Are you sure you have
recompiled and installed the new version?
Here is what I get with latest trunk ( I have my rls sever on 5070 and my
proxy on 5060):

Initial Subscribe and Notify:
U 2008/12/10 12:42:50.302010 192.168.2.132:5060 -> 192.168.2.132:5070
SUBSCRIBE sip:anca-list at 192.168.2.132 SIP/2.0.
Record-Route:
<sip:192.168.2.132;lr=on;ftag=tYhh7SHJRR395OUzDiZ6Jj7DkqbiqFtS>.
Via: SIP/2.0/UDP 192.168.2.132;branch=z9hG4bK4aef.9de66b4.0.
Via: SIP/2.0/UDP
192.168.2.132:60798;received=192.168.2.132;rport=60798;branch=z9hG4bKPjx-ZFVEz72zPCBm.26QfUJrE5.8cILj-I.
Max-Forwards: 69.
From: <sip:anca at 192.168.2.132>;tag=tYhh7SHJRR395OUzDiZ6Jj7DkqbiqFtS.
To: <sip:anca-list at 192.168.2.132>.
Contact: <sip:0fbeacc898 at 192.168.2.132:60798>.
Call-ID: .ei4OvgfjW1xdrwO5vof0wuZSctcMx7o.
CSeq: 3606 SUBSCRIBE.
Event: presence.
Expires: 300.
Accept: multipart/related.
Allow-Events: presence.winfo, message-summary, xcap-diff, presence.
User-Agent: ag-projects/sipclient-0.2.3-pjsip-1.0-trunk.
Supported: eventlist.
Content-Length:  0.
.


U 2008/12/10 12:42:50.303408 192.168.2.132:5070 -> 192.168.2.132:5060
SIP/2.0 200 OK.
Record-Route:
<sip:192.168.2.132;lr=on;ftag=tYhh7SHJRR395OUzDiZ6Jj7DkqbiqFtS>.
Via: SIP/2.0/UDP 192.168.2.132;branch=z9hG4bK4aef.9de66b4.0.
Via: SIP/2.0/UDP
192.168.2.132:60798;received=192.168.2.132;rport=60798;branch=z9hG4bKPjx-ZFVEz72zPCBm.26QfUJrE5.8cILj-I.
From: <sip:anca at 192.168.2.132>;tag=tYhh7SHJRR395OUzDiZ6Jj7DkqbiqFtS.
To:
<sip:anca-list at 192.168.2.132>;tag=bbf7d4ee170841f97da4789c46f9e5df-6231.
Call-ID: .ei4OvgfjW1xdrwO5vof0wuZSctcMx7o.
CSeq: 3606 SUBSCRIBE.
Expires: 300.
Contact: <sip:sa at 192.168.2.132:5070>.
Require: eventlist.
Server: OpenSIPS (1.5.0dev2-notls (i386/linux)).
Content-Length: 0.
.


U 2008/12/10 12:42:50.304922 192.168.2.132:5070 -> 192.168.2.132:5060
NOTIFY sip:0fbeacc898 at 192.168.2.132:60798 SIP/2.0.
Via: SIP/2.0/UDP 192.168.2.132:5070;branch=z9hG4bKa93b.6404ecb1.0.
To: sip:anca at 192.168.2.132;tag=tYhh7SHJRR395OUzDiZ6Jj7DkqbiqFtS.
From:
sip:anca-list at 192.168.2.132;tag=bbf7d4ee170841f97da4789c46f9e5df-6231.
CSeq: 1 NOTIFY.
Call-ID: .ei4OvgfjW1xdrwO5vof0wuZSctcMx7o.
Route: <sip:192.168.2.132;lr=on;ftag=tYhh7SHJRR395OUzDiZ6Jj7DkqbiqFtS>.
Content-Length: 437.
User-Agent: OpenSIPS (1.5.0dev2-notls (i386/linux)).
Max-Forwards: 70.
Event: presence.
Contact: <sip:sa at 192.168.2.132:5070>.
Subscription-State: active;expires=300.
Require: eventlist.
Content-Type: multipart/related;type="application/rlmi+xml";start=
"<1228905770.sip:anca-list at 192.168.2.132.1388638956>";boundary="HXViZAnDGnx6WEgIVJqjZtAK".
.
--HXViZAnDGnx6WEgIVJqjZtAK.
Content-Transfer-Encoding: binary.
Content-ID: <1228905770.sip:anca-list at 192.168.2.132.1388638956>.
Content-Type: application/rlmi+xml;charset="UTF-8r".
.
<?xml version="1.0"?>
<list uri="sip:anca-list at 192.168.2.132"
xmlns="urn:ietf:params:xml:ns:rlmi" version="1" fullState="true">
  <resource uri="sip:anca at 192.168.2.132"/>
  <resource uri="sip:test at 192.168.2.132"/>
</list>
.
--HXViZAnDGnx6WEgIVJqjZtAK--.


U 2008/12/10 12:42:50.318589 192.168.2.132:5060 -> 192.168.2.132:5070
SIP/2.0 200 OK.
Via: SIP/2.0/UDP 192.168.2.132:5070;branch=z9hG4bKa93b.6404ecb1.0.
Call-ID: .ei4OvgfjW1xdrwO5vof0wuZSctcMx7o.
From:
<sip:anca-list at 192.168.2.132>;tag=bbf7d4ee170841f97da4789c46f9e5df-6231.
To: <sip:anca at 192.168.2.132>;tag=tYhh7SHJRR395OUzDiZ6Jj7DkqbiqFtS.
CSeq: 1 NOTIFY.
Contact: <sip:0fbeacc898 at 192.168.2.132:60798>.
Allow: SUBSCRIBE, NOTIFY, PRACK, INVITE, ACK, BYE, CANCEL, UPDATE,
MESSAGE.
Supported: 100rel.
Content-Length:  0.

Subsequent Subscribe and Notify:

U 2008/12/10 12:43:02.763386 192.168.2.132:5060 -> 192.168.2.132:5070
SUBSCRIBE sip:sa at 192.168.2.132:5070 SIP/2.0.
Via: SIP/2.0/UDP 192.168.2.132;branch=z9hG4bK5aef.08b10387.0.
Via: SIP/2.0/UDP
192.168.2.132:60798;received=192.168.2.132;rport=60798;branch=z9hG4bKPjpl9dFS5GA9NIY.dZASYV2yYZr4Nu2Mn2.
Max-Forwards: 69.
From: <sip:anca at 192.168.2.132>;tag=tYhh7SHJRR395OUzDiZ6Jj7DkqbiqFtS.
To:
<sip:anca-list at 192.168.2.132>;tag=bbf7d4ee170841f97da4789c46f9e5df-6231.
Contact: <sip:0fbeacc898 at 192.168.2.132:60798>.
Call-ID: .ei4OvgfjW1xdrwO5vof0wuZSctcMx7o.
CSeq: 3607 SUBSCRIBE.
Event: presence.
Expires: 0.
Accept: multipart/related.
Allow-Events: presence.winfo, message-summary, xcap-diff, presence.
User-Agent: ag-projects/sipclient-0.2.3-pjsip-1.0-trunk.
Supported: eventlist.
Content-Length:  0.
P-hint: rr-enforced.
.


U 2008/12/10 12:43:02.764563 192.168.2.132:5070 -> 192.168.2.132:5060
SIP/2.0 200 OK.
Via: SIP/2.0/UDP 192.168.2.132;branch=z9hG4bK5aef.08b10387.0.
Via: SIP/2.0/UDP
192.168.2.132:60798;received=192.168.2.132;rport=60798;branch=z9hG4bKPjpl9dFS5GA9NIY.dZASYV2yYZr4Nu2Mn2.
From: <sip:anca at 192.168.2.132>;tag=tYhh7SHJRR395OUzDiZ6Jj7DkqbiqFtS.
To:
<sip:anca-list at 192.168.2.132>;tag=bbf7d4ee170841f97da4789c46f9e5df-6231.
Call-ID: .ei4OvgfjW1xdrwO5vof0wuZSctcMx7o.
CSeq: 3607 SUBSCRIBE.
Expires: 0.
Contact: <sip:sa at 192.168.2.132:5070>.
Require: eventlist.
Server: OpenSIPS (1.5.0dev2-notls (i386/linux)).
Content-Length: 0.
.


U 2008/12/10 12:43:02.765773 192.168.2.132:5070 -> 192.168.2.132:5060
NOTIFY sip:0fbeacc898 at 192.168.2.132:60798 SIP/2.0.
Via: SIP/2.0/UDP 192.168.2.132:5070;branch=z9hG4bK793b.a3db3e03.0.
To: sip:anca at 192.168.2.132;tag=tYhh7SHJRR395OUzDiZ6Jj7DkqbiqFtS.
From:
sip:anca-list at 192.168.2.132;tag=bbf7d4ee170841f97da4789c46f9e5df-6231.
CSeq: 2 NOTIFY.
Call-ID: .ei4OvgfjW1xdrwO5vof0wuZSctcMx7o.
Route: <sip:192.168.2.132;lr=on;ftag=tYhh7SHJRR395OUzDiZ6Jj7DkqbiqFtS>.
Content-Length: 437.
User-Agent: OpenSIPS (1.5.0dev2-notls (i386/linux)).
Max-Forwards: 70.
Event: presence.
Contact: <sip:sa at 192.168.2.132:5070>.
Subscription-State: terminated;reason=timeout.
Require: eventlist.
Content-Type: multipart/related;type="application/rlmi+xml";start=
"<1228905782.sip:anca-list at 192.168.2.132.1973250666>";boundary="EnFWYBCacVbNJvhpjk6JakMf".
.
--EnFWYBCacVbNJvhpjk6JakMf.
Content-Transfer-Encoding: binary.
Content-ID: <1228905782.sip:anca-list at 192.168.2.132.1973250666>.
Content-Type: application/rlmi+xml;charset="UTF-8r".
.
<?xml version="1.0"?>
<list uri="sip:anca-list at 192.168.2.132"
xmlns="urn:ietf:params:xml:ns:rlmi" version="2" fullState="true">
  <resource uri="sip:anca at 192.168.2.132"/>
  <resource uri="sip:test at 192.168.2.132"/>
</list>
.
--EnFWYBCacVbNJvhpjk6JakMf--.

U 2008/12/10 12:43:02.774232 192.168.2.132:5060 -> 192.168.2.132:5070
SIP/2.0 200 OK.
Via: SIP/2.0/UDP 192.168.2.132:5070;branch=z9hG4bK793b.a3db3e03.0.
Call-ID: .ei4OvgfjW1xdrwO5vof0wuZSctcMx7o.
From:
<sip:anca-list at 192.168.2.132>;tag=bbf7d4ee170841f97da4789c46f9e5df-6231.
To: <sip:anca at 192.168.2.132>;tag=tYhh7SHJRR395OUzDiZ6Jj7DkqbiqFtS.
CSeq: 2 NOTIFY.
Contact: <sip:0fbeacc898 at 192.168.2.132:60798>.
Allow: SUBSCRIBE, NOTIFY, PRACK, INVITE, ACK, BYE, CANCEL, UPDATE,
MESSAGE.
Supported: 100rel.
Content-Length:  0.
.

regards,

Anca


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

Comment By: Nathan (rmnathan)
Date: 2008-12-09 16:18

Message:
Hi Anca,
Thank you for the reply. I have attached entire opensips log and pcap
file.
For detail call flow please see the pcap file.

Regards,
Nathan


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

Comment By: Anca Vamanu (anca_vamanu)
Date: 2008-12-09 14:40

Message:
Hi Nathan,

I have tested myself now(without calling record_route on in dialog
SUBSCRIBE) and it works. The Notify sent by the RLS server has the right
Route header and passes through the proxy.
Can you provide some trace on rls server for the subsequent Subscribe and
the triggered Notify?

regards,
Anca

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

Comment By: Nathan (rmnathan)
Date: 2008-12-08 16:38

Message:
Hi Anca,
I have tested with latest trunk build. Iam getting the same error ( ie
opensips is sending NOTIFY message directly to UE for refresh SUBSCRIBE.). 

Regards,
Nathan



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

Comment By: Anca Vamanu (anca_vamanu)
Date: 2008-12-08 13:45

Message:
Hi Nathan, 

Thank you for the report. Indeed there was a miss out there that lead to
only the route set from the received Subscribe to be added instead of the
route set from the initial subscribe. It is fixed now both in trunk and the
stable 1.4.x branch.

regards,
Anca

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

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


From noreply at sourceforge.net  Thu Feb 19 13:09:13 2009
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 19 Feb 2009 12:09:13 +0000
Subject: [OpenSIPS-Devel] [ opensips-Bugs-2186836 ] PUA_BLA fails for UA's
	registered behind NAT
Message-ID: <E1La7iL-0003HG-O9@g45xhf1.ch3.sourceforge.com>

Bugs item #2186836, was opened at 2008-10-22 16:26
Message generated for change (Settings changed) made by anca_vamanu
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=2186836&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: I?aki Baz (ibc_sf)
Assigned to: Anca Vamanu (anca_vamanu)
Summary: PUA_BLA fails for UA's registered behind NAT

Initial Comment:
I'm trying PUA_BLA with phones behind NAT. When the REGISTER arrives I do "fix_nated_register()" so the original Contact:
  Contact: <sip:user at 192.168.1.100:5060>
becomes:
  Contact: <sip:user at 192.168.1.100:5060;received=80.80.12.54:34567>


After that I do "bla_set_flag()" so PUA_BLA generates a SUBSCRIBE that should arrive to the UA, but PUA_BLA generates it:

  SUBSCRIBE sip:user at 192.168.1.100:5060

So this SUBSCRIBE will never arrive to the UAC since it's a private IP. The SUBSCRIBE should be sent to the "received" parameter (added before) but I don't know how to achieve it.

A dirty workaround is doing "fix_natted_contact()" before "bla_set_flag()" but this is a bad idea since it will change the stored Contact URI in "location" table (and normally UA's need to see their same private IP in
the RURI of requests sent from the proxy).

As a suggestion, PUA_BLA should take in account the "received" parameter added in Contact during registration to send the SUBSCRIBE.

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

Comment By: I?aki Baz (ibc_sf)
Date: 2008-12-10 18:48

Message:
Hi Anca, unfortunatelly I have no access to Polycom phones anymore so I
cannot test the new code.
Could somebody test it?

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

Comment By: I?aki Baz (ibc_sf)
Date: 2008-12-08 16:51

Message:
Sorry, I had this scenario temporaly dissabled. Let me to check it during
this week.

Thanks a lot.

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

Comment By: Anca Vamanu (anca_vamanu)
Date: 2008-12-08 14:40

Message:
Hi Inaki,

Can you please provide a feedback to this as I would like to close this
bug report.

regards,
Anca 

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

Comment By: I?aki Baz (ibc_sf)
Date: 2008-10-22 16:43

Message:
Thanks a lot, I'll try it ASAP and comment here the result.

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

Comment By: Anca Vamanu (anca_vamanu)
Date: 2008-10-22 16:31

Message:
Hi Inaki,

I have just commited a fix for this. Please test and let me know if it
works.

regards,
Anca Vamanu


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

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


From noreply at sourceforge.net  Thu Feb 19 13:10:49 2009
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 19 Feb 2009 12:10:49 +0000
Subject: [OpenSIPS-Devel] [ opensips-Bugs-2173727 ] presence: NOTIFY to tel:
	URI fails
Message-ID: <E1La7jt-0001mJ-Ra@155xhf1.ch3.sourceforge.com>

Bugs item #2173727, was opened at 2008-10-17 06:45
Message generated for change (Settings changed) made by anca_vamanu
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=2173727&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: Rejected
Priority: 5
Private: No
Submitted By: Phil Vandry (vandry)
Assigned to: Anca Vamanu (anca_vamanu)
Summary: presence: NOTIFY to tel: URI fails

Initial Comment:
The presence module must remember the URI in the To: header of a SUBSCRIBE request and copy it to the From: header of an outgoing NOTIFY request. This works for sip URIs but fails for tel URIs.

Actually it parses the URI as user at domain and stores the user & domain seperately in the database so it looks like it was not designed to work with tel: URIs.

The attached patch implements a workaround: a tel: URI will be saved with the telephone number in the username field and a blank domain; when this information needs to be converted back to a URI, a blank domain signals that a tel: URI should be generated. Actually this is OK since a sip: URI can never contain a blank domain.

With this patch, it is possible to subscribe to a presentity for presence using a tel: URI.

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

Comment By: I?aki Baz (ibc_sf)
Date: 2008-10-24 16:24

Message:
A new reply:

-------------
I can think of no reason why a TEL should not be permitted. Presumably it
would be routed the same way an INVITE would. Eventually that should lead
to some UA, perhaps a GW, perhaps a native sip device. Either way the
SUBSCRIBE *might* be supported. If the subscribe isn't supported then an
error is reported.
So I consider this a bug in the spec.
-------------

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

Comment By: I?aki Baz (ibc_sf)
Date: 2008-10-24 15:13

Message:
A reply in SIP-implementors:

--------
IMO "pres" uri is meant for presentity/watchers participants for
"presence" and related event packages.
"sip" scheme is more generic and may include "sip protocol"
participants including call and "presence".
All these schemes are meant for IP domain. TEL scheme is defined to
accommodate E.164 numbers from non-IP domain and SUBSCRIBE/NOTIFY
framework is not defined for these entities unless you have some ENUM
mapping available
I am not sure whether this is convincing enough.
---------

Thread:
https://lists.cs.columbia.edu/pipermail/sip-implementors/2008-October/020744.html


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

Comment By: I?aki Baz (ibc_sf)
Date: 2008-10-22 19:31

Message:
I've sent a mail to SIP-implementors about TEL URI in SUBSCRIBE:

 
https://lists.cs.columbia.edu/pipermail/sip-implementors/2008-October/020744.html

Let's wait for replies and explanations.

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

Comment By: Phil Vandry (vandry)
Date: 2008-10-22 18:22

Message:
I am surprised to learn about the limitation in RFC 3856. Please note
however the following:

- subscribing to tel: URIs for presence is done in practice despite this
limitation and works fine. Relaxing this limitation is required to
interoperate with clients and RLS servers that do this. I agree with Klaus
that that the limitation is unnecessary.
- The issue I raised with OpenSIPS is actually in the generic subscription
handling module, not in the presence event package. I am not aware of
anything in RFC 3265 that restricts the kind of URIs that may appear in
From: and To:.

Regarding I?aki's comment, I am not sure why you imply that it is
illogical to subscribe to a TEL URI. If I would like to subscribe to
someone's presence and all I have is their telephone number then why should
I not subscribe to it? Actually the average end-user is more likely to know
telephone numbers for their friends than SIP URIs.

I will still point out the limitation in RFC 3856 to some people here.

-Phil

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

Comment By: I?aki Baz (ibc_sf)
Date: 2008-10-22 16:24

Message:
It's logical to subscribe to a SIP/SIPS uri, but what does it mean
subscribing to a TEL URI?
A SIP/SIPS URI means an user that is locates somewhere while a TEL URI
means a telephony destination, not an user.

I'm not 100% sure of what I've said, but I think there can be good reasons
to disallow abstract URI's as TEL in subscriptions. Perhaps we should ask
in sip-implementors maillist since I read a thread about it some weeks ago.

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

Comment By: I?aki Baz (ibc_sf)
Date: 2008-10-22 16:19

Message:
It's logical to subscribe to a SIP/SIPS uri, but what does it mean
subscribing to a TEL URI?
A SIP/SIPS URI means an user that is locates somewhere while a TEL URI
means a telephony destination, not an user.

I'm not 100% sure of what I've said, but I think there can be good reasons
to disallow abstract URI's as TEL in subscriptions. Perhaps we should ask
in sip-implementors maillist since I read a thread about it some weeks ago.

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

Comment By: Klaus Darilion (klaus_darilion)
Date: 2008-10-22 13:35

Message:
IMO this is an unnecessary limitation in RFC 3856. We should discuss this
on the SIP list.



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

Comment By: Anca Vamanu (anca_vamanu)
Date: 2008-10-22 13:05

Message:
Hi Phil,

I have looked through the SIP Presence Event Package RFC( 3856 ) and it
seems that in fact, the to and from of a Subscribe request can not be tel
uri's.

Section 5. 

SUBSCRIBE messages also contain logical identifiers that define the
   originator and recipient of the subscription (the To and From header
   fields).  These headers can take either a pres or SIP URI. 

This still lets the pres uri problem, which will not work. Our presence
module in fact does not have support for pres uri's neigther in RURI's. I
will open a bug report to remind me to fix this.

regards,
Anca Vamanu



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

Comment By: Phil Vandry (vandry)
Date: 2008-10-20 02:53

Message:
OK, I will change this to handle and type of URI by saving the original URI
verbatim instead of breaking it up into username & password. However, this
will cause the database schema to change.

-Phil

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

Comment By: I?aki Baz (ibc_sf)
Date: 2008-10-19 01:42

Message:
I agree with Klaus. A cleaner solution would be to store also the protocol
in the table.

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

Comment By: Nobody/Anonymous (nobody)
Date: 2008-10-17 11:12

Message:
I wonder why the URI is split into userpart and domain at all.

Your patch is a workaround for tel URIs, but not a generic solution (what
about http URIs :-)

klaus

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

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


From saguti at gmail.com  Thu Feb 19 16:23:31 2009
From: saguti at gmail.com (Sergio Gutierrez)
Date: Thu, 19 Feb 2009 15:23:31 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[5346]
	trunk/modules/db_berkeley/Makefile
Message-ID: <E1LaAkN-0004cr-0I@d5vjzd1.ch3.sourceforge.com>

Revision: 5346
          http://opensips.svn.sourceforge.net/opensips/?rev=5346&view=rev
Author:   saguti
Date:     2009-02-19 15:23:30 +0000 (Thu, 19 Feb 2009)

Log Message:
-----------
- Fix order of includes. Backport from Kamailio, revision 5624 (Credits go to Jan Janak)

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

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


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


From saguti at gmail.com  Thu Feb 19 16:25:16 2009
From: saguti at gmail.com (Sergio Gutierrez)
Date: Thu, 19 Feb 2009 15:25:16 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[5347]
	branches/1.4/modules/db_berkeley/Makefile
Message-ID: <E1LaAm4-0004eX-Fd@d5vjzd1.ch3.sourceforge.com>

Revision: 5347
          http://opensips.svn.sourceforge.net/opensips/?rev=5347&view=rev
Author:   saguti
Date:     2009-02-19 15:25:13 +0000 (Thu, 19 Feb 2009)

Log Message:
-----------
- Fix order of includes. Backport from Kamailio, revision 5624 (Credits go to Jan Janak)

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

Modified Paths:
--------------
    branches/1.4/modules/db_berkeley/Makefile


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


From saguti at gmail.com  Thu Feb 19 17:37:37 2009
From: saguti at gmail.com (Sergio Gutierrez)
Date: Thu, 19 Feb 2009 16:37:37 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[5348]
 branches/1.4/modules/alias_db/doc/ alias_db_admin.xml
Message-ID: <E1LaBu5-0006Q2-PO@c3vjzd1.ch3.sourceforge.com>

Revision: 5348
          http://opensips.svn.sourceforge.net/opensips/?rev=5348&view=rev
Author:   saguti
Date:     2009-02-19 16:37:37 +0000 (Thu, 19 Feb 2009)

Log Message:
-----------
- Fixed small typos and grammar.

Modified Paths:
--------------
    branches/1.4/modules/alias_db/doc/alias_db_admin.xml


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


From saguti at gmail.com  Thu Feb 19 17:37:50 2009
From: saguti at gmail.com (Sergio Gutierrez)
Date: Thu, 19 Feb 2009 16:37:50 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[5349]
	trunk/modules/alias_db/doc/alias_db_admin.xml
Message-ID: <E1LaBuI-0006QI-Lp@c3vjzd1.ch3.sourceforge.com>

Revision: 5349
          http://opensips.svn.sourceforge.net/opensips/?rev=5349&view=rev
Author:   saguti
Date:     2009-02-19 16:37:50 +0000 (Thu, 19 Feb 2009)

Log Message:
-----------
- Fixed small typos and grammar.

Modified Paths:
--------------
    trunk/modules/alias_db/doc/alias_db_admin.xml


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


From saguti at gmail.com  Thu Feb 19 18:37:01 2009
From: saguti at gmail.com (Sergio Gutierrez)
Date: Thu, 19 Feb 2009 17:37:01 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[5350]
	branches/1.4/modules/auth/doc/auth_admin.xml
Message-ID: <E1LaCpZ-0005mp-Kw@74yxhf1.ch3.sourceforge.com>

Revision: 5350
          http://opensips.svn.sourceforge.net/opensips/?rev=5350&view=rev
Author:   saguti
Date:     2009-02-19 17:37:01 +0000 (Thu, 19 Feb 2009)

Log Message:
-----------
- Fixed typos and grammar.

Modified Paths:
--------------
    branches/1.4/modules/auth/doc/auth_admin.xml


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


From saguti at gmail.com  Thu Feb 19 18:37:11 2009
From: saguti at gmail.com (Sergio Gutierrez)
Date: Thu, 19 Feb 2009 17:37:11 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[5351]
	trunk/modules/auth/doc/auth_admin.xml
Message-ID: <E1LaCpj-0005nT-OY@74yxhf1.ch3.sourceforge.com>

Revision: 5351
          http://opensips.svn.sourceforge.net/opensips/?rev=5351&view=rev
Author:   saguti
Date:     2009-02-19 17:37:11 +0000 (Thu, 19 Feb 2009)

Log Message:
-----------
- Fixed typos and grammar.

Modified Paths:
--------------
    trunk/modules/auth/doc/auth_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 Feb 19 23:28:58 2009
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 19 Feb 2009 22:28:58 +0000
Subject: [OpenSIPS-Devel] [ opensips-Support Requests-2617831 ] WARNING:
	database engine not found - tried 'MYSQL'
Message-ID: <E1LaHO6-0005yA-Mq@b55xhf1.ch3.sourceforge.com>

Support Requests item #2617831, was opened at 2009-02-19 17:28
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086411&aid=2617831&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: Install Problem
Group: None
Status: Open
Priority: 5
Private: No
Submitted By: Steve (mysticreporterr)
Assigned to: Nobody/Anonymous (nobody)
Summary: WARNING: database engine not found - tried 'MYSQL'

Initial Comment:
After following the steps on the install document posted on the OpenSips website, building from source on a Fedora machine, it would appear that it won't start when I run.

Here is command window text:
-----------------------------------
[ sbin]# opensipsctl start
WARNING: database engine not found - tried 'MYSQL'

INFO: Starting OpenSIPS :

ERROR: PID file /var/run/opensips.pid does not exist -- OpenSIPS start failed
-----------------------------------


I followed another unresolved thread and found the following:


-----------------------------------
[ sbin]# cd /usr/local/lib/opensips
[ opensips]# ls
modules  opensipsctl
[ opensips]# cd opensipsctl
[ opensipsctl]# ls
dbtextdb          opensipsctl.ctlbase  opensipsctl.fifo     opensipsctl.unixsock  opensipsdbctl.dbtext
opensipsctl.base  opensipsctl.dbtext   opensipsctl.sqlbase  opensipsdbctl.base
-----------------------------------

Any solutions?

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

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


From noreply at sourceforge.net  Fri Feb 20 00:42:17 2009
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 19 Feb 2009 23:42:17 +0000
Subject: [OpenSIPS-Devel] [ opensips-Bugs-2538399 ] Bug in presence when
	using fallback2db
Message-ID: <E1LaIX3-0006OX-FS@1bkjzd1.ch3.sourceforge.com>

Bugs item #2538399, was opened at 2009-01-26 14:39
Message generated for change (Comment added) made by oren_k
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=2538399&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: Oren K (oren_k)
Assigned to: Anca Vamanu (anca_vamanu)
Summary: Bug in presence when using fallback2db

Initial Comment:
Hi,

While using the presence module, I run this scenario:

a. user1 SUBSCRIBE's to presence of user2
(subscription is now pending)

b. user2 allows user1 in pres-rules
(refreshWatchers is called, subscription is now active. user1 receives a NOTIFY from presence server with user2's current tuple and Subscription-State: active)

c. user2 PUBLISH'es a new presence tuple
-- at this point presence server should NOTIFY user1 of the new presence but it doesn't (that's the bug).


My modparams:

modparam("presence|presence_xml", "db_url", "mysql://root at localhost/opensips")

modparam("presence", "server_address", "sip:presence.example.com:10500")

modparam("presence", "fallback2db", 1)
modparam("presence", "clean_period", 30)


What I see in the debug trace is that get_subs_dialog (from notify.c) can't find any dialogs in the database, and all those in the subs hash are flagged NO_UPDATEDB_FLAG. This is probably what's causing the problem. 
Strangely, in the above scenario if user1 un-SUBSCRIBEs and re-SUBSCRIBEs to user2's presence - it does receive notifications.

Regards,
Oren K.

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

>Comment By: Oren K (oren_k)
Date: 2009-02-19 18:42

Message:
Still no joy.. adding updated log and pcap for the version i compiled from
svn 1.5.0dev5-tls.

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

Comment By: Anca Vamanu (anca_vamanu)
Date: 2009-02-18 11:11

Message:
Hi, 

I have just now made some changes in presence module for fallback2db case.
Can you please update to the newest svn version for 1.5 and test again?

regards,
Anca

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

Comment By: Anca Vamanu (anca_vamanu)
Date: 2009-02-18 11:10

Message:
Hi, 

I have just now made some changes in presence module for fallback2db case.
Can you please update to the newest svn version for 1.5 and test again?

regards,
Anca

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

Comment By: Oren K (oren_k)
Date: 2009-02-06 19:23

Message:
Hi Anca,

I've attached a debug-log and wireshark pcap file to the post. The pcap
file also contains the XCAP PUTs to change the presence rules. The only
error in the log comes from presence_xml not being able to extract a tuple
node because our client uses <pdm:person> for the presence (Same bug
happened to us when we tried with <tuple> so that's not the issue). The
things that strike me odd in presence_bug.log are:

(after step b. user2 allows user1 in pres-rules)
line 634: DBG:presence:update_pw_dialogs: found 1 matching dialogs

the module finds the watcher dialog and updates it due to refreshWatchers.
user1 receives a NOTIFY with Subscription-State:active. Now step c. user2
PUBLISH'es a new presence tuple:

line 919: DBG:core:parse_msg:  method:  <PUBLISH>

everything looks okay BUT:

line 1087: DBG:presence:get_subs_db: The query for subscribtion for [uri]=
sip:user2 at openims.summit-tech.ca for [event]= presence returned no result
line 1110: DBG:presence:get_subs_dialog: s->db_flag== UPDATEDB_FLAG
line 1111: DBG:presence:get_subs_dialog: found 0 dialogs( 0 in database
and 0 in hash_table)
line 1112: DBG:presence:publ_notify: Could not find subs_dialog

..suddenly there are no subscribers?

Thanks.


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

Comment By: Anca Vamanu (anca_vamanu)
Date: 2009-02-06 13:14

Message:
Hi Oren,

I have just downloaded myself the release and tested and the scenario that
you described works. 
Do you notice any error in your log file?

regards,
Anca

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

Comment By: Oren K (oren_k)
Date: 2009-02-01 11:41

Message:
Sorry I forgot to login, that comment is from me :)

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

Comment By: Nobody/Anonymous (nobody)
Date: 2009-01-28 10:12

Message:
Thanks for the reply anca. Version is opensips-1.4.4-tls, compiled from the
sources with TLS="1". 

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

Comment By: Anca Vamanu (anca_vamanu)
Date: 2009-01-28 06:48

Message:
Hi Oren,

What OpenSIPS version are you using? Trunk or stable release?

regards,
Anca

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

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


From noreply at sourceforge.net  Fri Feb 20 00:49:19 2009
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 19 Feb 2009 23:49:19 +0000
Subject: [OpenSIPS-Devel] [ opensips-Support Requests-2617831 ] WARNING:
	database engine not found - tried 'MYSQL'
Message-ID: <E1LaIdr-0000DR-5t@h45xhf1.ch3.sourceforge.com>

Support Requests item #2617831, was opened at 2009-02-19 23:28
Message generated for change (Comment added) made by ibc_sf
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086411&aid=2617831&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: Install Problem
Group: None
Status: Open
Priority: 5
Private: No
Submitted By: Steve (mysticreporterr)
Assigned to: Nobody/Anonymous (nobody)
Summary: WARNING: database engine not found - tried 'MYSQL'

Initial Comment:
After following the steps on the install document posted on the OpenSips website, building from source on a Fedora machine, it would appear that it won't start when I run.

Here is command window text:
-----------------------------------
[ sbin]# opensipsctl start
WARNING: database engine not found - tried 'MYSQL'

INFO: Starting OpenSIPS :

ERROR: PID file /var/run/opensips.pid does not exist -- OpenSIPS start failed
-----------------------------------


I followed another unresolved thread and found the following:


-----------------------------------
[ sbin]# cd /usr/local/lib/opensips
[ opensips]# ls
modules  opensipsctl
[ opensips]# cd opensipsctl
[ opensipsctl]# ls
dbtextdb          opensipsctl.ctlbase  opensipsctl.fifo     opensipsctl.unixsock  opensipsdbctl.dbtext
opensipsctl.base  opensipsctl.dbtext   opensipsctl.sqlbase  opensipsdbctl.base
-----------------------------------

Any solutions?

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

Comment By: I?aki Baz (ibc_sf)
Date: 2009-02-20 00:49

Message:
Steve, a bug tracker is not a place in which users should ask basic
questions about how to run OpenSIPS for the first time.
Such a question should take place in the OpenSIPS users maillist.

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

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


From noreply at sourceforge.net  Fri Feb 20 00:51:20 2009
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 19 Feb 2009 23:51:20 +0000
Subject: [OpenSIPS-Devel] [ opensips-Support Requests-2617831 ] WARNING:
	database engine not found - tried 'MYSQL'
Message-ID: <E1LaIfo-0003M7-7O@d55xhf1.ch3.sourceforge.com>

Support Requests item #2617831, was opened at 2009-02-19 23:28
Message generated for change (Comment added) made by ibc_sf
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086411&aid=2617831&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: Install Problem
Group: None
Status: Open
Priority: 5
Private: No
Submitted By: Steve (mysticreporterr)
Assigned to: Nobody/Anonymous (nobody)
Summary: WARNING: database engine not found - tried 'MYSQL'

Initial Comment:
After following the steps on the install document posted on the OpenSips website, building from source on a Fedora machine, it would appear that it won't start when I run.

Here is command window text:
-----------------------------------
[ sbin]# opensipsctl start
WARNING: database engine not found - tried 'MYSQL'

INFO: Starting OpenSIPS :

ERROR: PID file /var/run/opensips.pid does not exist -- OpenSIPS start failed
-----------------------------------


I followed another unresolved thread and found the following:


-----------------------------------
[ sbin]# cd /usr/local/lib/opensips
[ opensips]# ls
modules  opensipsctl
[ opensips]# cd opensipsctl
[ opensipsctl]# ls
dbtextdb          opensipsctl.ctlbase  opensipsctl.fifo     opensipsctl.unixsock  opensipsdbctl.dbtext
opensipsctl.base  opensipsctl.dbtext   opensipsctl.sqlbase  opensipsdbctl.base
-----------------------------------

Any solutions?

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

Comment By: I?aki Baz (ibc_sf)
Date: 2009-02-20 00:51

Message:
Well, sorry, I didn't realize that the question was in the "Support
Requests" section. Anyhow I recommend you to ask the question in the users
maillist, full of activity.

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

Comment By: I?aki Baz (ibc_sf)
Date: 2009-02-20 00:49

Message:
Steve, a bug tracker is not a place in which users should ask basic
questions about how to run OpenSIPS for the first time.
Such a question should take place in the OpenSIPS users maillist.

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

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


From noreply at sourceforge.net  Fri Feb 20 01:21:09 2009
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 20 Feb 2009 00:21:09 +0000
Subject: [OpenSIPS-Devel] [ opensips-Support Requests-2617831 ] WARNING:
	database engine not found - tried 'MYSQL'
Message-ID: <E1LaJ8f-0003tT-PH@cdv4jf1.ch3.sourceforge.com>

Support Requests item #2617831, was opened at 2009-02-19 17:28
Message generated for change (Comment added) made by saguti
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086411&aid=2617831&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: Install Problem
Group: None
Status: Open
Priority: 5
Private: No
Submitted By: Steve (mysticreporterr)
Assigned to: Nobody/Anonymous (nobody)
Summary: WARNING: database engine not found - tried 'MYSQL'

Initial Comment:
After following the steps on the install document posted on the OpenSips website, building from source on a Fedora machine, it would appear that it won't start when I run.

Here is command window text:
-----------------------------------
[ sbin]# opensipsctl start
WARNING: database engine not found - tried 'MYSQL'

INFO: Starting OpenSIPS :

ERROR: PID file /var/run/opensips.pid does not exist -- OpenSIPS start failed
-----------------------------------


I followed another unresolved thread and found the following:


-----------------------------------
[ sbin]# cd /usr/local/lib/opensips
[ opensips]# ls
modules  opensipsctl
[ opensips]# cd opensipsctl
[ opensipsctl]# ls
dbtextdb          opensipsctl.ctlbase  opensipsctl.fifo     opensipsctl.unixsock  opensipsdbctl.dbtext
opensipsctl.base  opensipsctl.dbtext   opensipsctl.sqlbase  opensipsdbctl.base
-----------------------------------

Any solutions?

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

Comment By: Sergio Gutierrez (saguti)
Date: 2009-02-19 19:21

Message:
Hello Steve.

Could you provide more details about what commands did you use on you
build?
What version of OpenSIPS are you using?

Regards.

Sergio.

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

Comment By: I?aki Baz (ibc_sf)
Date: 2009-02-19 18:51

Message:
Well, sorry, I didn't realize that the question was in the "Support
Requests" section. Anyhow I recommend you to ask the question in the users
maillist, full of activity.

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

Comment By: I?aki Baz (ibc_sf)
Date: 2009-02-19 18:49

Message:
Steve, a bug tracker is not a place in which users should ask basic
questions about how to run OpenSIPS for the first time.
Such a question should take place in the OpenSIPS users maillist.

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

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


From noreply at sourceforge.net  Fri Feb 20 11:28:30 2009
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 20 Feb 2009 10:28:30 +0000
Subject: [OpenSIPS-Devel] [ opensips-Bugs-2523454 ] Error in handling rls
	NOTIFY
Message-ID: <E1LaScQ-0001CL-6t@d45xhf1.ch3.sourceforge.com>

Bugs item #2523454, was opened at 2009-01-20 17:25
Message generated for change (Comment added) made by rmnathan
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=2523454&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: Nathan (rmnathan)
Assigned to: Anca Vamanu (anca_vamanu)
Summary: Error in handling rls NOTIFY

Initial Comment:
Hi
The following error message are printed while handling rls notify.
Jan 20 06:45:44 [7833] ERROR:rls:parse_subs_state: terminated state and no reason foundJan 20 06:45:44 [7833] ERROR:rls:rls_handle_notify: while parsing 'Subscription-State' header
Jan 20 06:45:44 [7833] ERROR:rls:parse_subs_state: terminated state and no reason foundJan 20 06:45:44 [7833] ERROR:rls:rls_handle_notify: while parsing 'Subscription-State' header
Jan 20 06:45:44 [7833] ERROR:rls:parse_subs_state: terminated state and no reason foundJan 20 06:45:44 [7833] ERROR:rls:rls_handle_notify: while parsing 'Subscription-State' header
Jan 20 06:45:52 [7833] ERROR:rls:parse_subs_state: terminated state and no reason foundJan 20 06:45:52 [7833] ERROR:rls:rls_handle_notify: while parsing 'Subscription-State' header
Jan 20 06:45:52 [7833] ERROR:rls:parse_subs_state: terminated state and no reason foundJan 20 06:45:52 [7833] ERROR:rls:rls_handle_notify: while parsing 'Subscription-State' header
Jan 20 06:46:13 [7834] ERROR:core:db_do_insert: invalid parameter value
Jan 20 06:46:13 [7834] ERROR:pua:db_update: while inserting in db table pua
Jan 20 06:46:43 [7834] ERROR:core:parse_uri: uri too short: <> (0)
Jan 20 06:46:43 [7834] ERROR:tm:uri2proxy: bad_uri:
Jan 20 06:46:43 [7834] ERROR:tm:uri2su: failed create a dst proxy
Jan 20 06:46:43 [7834] ERROR:tm:t_uac: no socket found
Jan 20 06:46:43 [7834] ERROR:pua:update_pua: in t_request function
Jan 20 06:46:43 [7834] ERROR:pua:hashT_clean: while updating record
Jan 20 06:47:05 [7833] ERROR:rls:parse_subs_state: terminated state and no reason foundJan 20 06:47:05 [7833] ERROR:rls:rls_handle_notify: while parsing 'Subscription-State' header

Regards,
rmnathan


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

Comment By: Nathan (rmnathan)
Date: 2009-02-20 15:58

Message:
Hi Anca,
You are correct . That is not presence or rls server. It is registrar
(scscf) running on 192.168.166.150:50606. 
Please let me know if you want any information.

Thanks lot
rmnathan

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

Comment By: Anca Vamanu (anca_vamanu)
Date: 2009-02-19 17:33

Message:
Hi Rmnathan,

I looked through your trace but something is confusing.
Can you please tell me what was running on 192.168.166.150 port 50606. I
see that the User-Agent header is OpenSIPS, but the behavior doesn't seem
like that of a presence or rls server.

regards,
Anca

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

Comment By: Nathan (rmnathan)
Date: 2009-02-02 14:44

Message:
Hi Anca.
Yes, am using opensips as presence server and rls server. Please find the
logs and pcap file for call flow attached.

Regards,
rmnathan


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

Comment By: Anca Vamanu (anca_vamanu)
Date: 2009-01-22 18:55

Message:
Hi rmnathan,

Thank you for this report also.
There is something wrong with that Notify that gives this error.
Can you please trace the trafic and catch a Notify that generates this
error and print it here?
This Notify is received from the presence server. Are you using also
OpenSIPS as the presence server? Can you please check is the source IP
address of the Notify message is that of the presence server?

regards,
Anca

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

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


From noreply at sourceforge.net  Fri Feb 20 11:46:21 2009
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 20 Feb 2009 10:46:21 +0000
Subject: [OpenSIPS-Devel] [ opensips-Bugs-2608188 ] OpenSIPS latest trunk
	libmysqlclient segfault
Message-ID: <E1LaSth-0004U8-Bq@b55xhf1.ch3.sourceforge.com>

Bugs item #2608188, was opened at 2009-02-17 07:02
Message generated for change (Comment added) made by ibc_sf
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=2608188&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: 8
Private: No
Submitted By: Om Bikram Thapa (omthapa)
Assigned to: Bogdan-Andrei Iancu (bogdan_iancu)
Summary: OpenSIPS latest trunk libmysqlclient segfault 

Initial Comment:
OpenSIPS latest trunk on Debian Lenny/AMD64 dies with libmysqlclient segfault after a MySQL restart. The event that triggers this crash is registration related database query immediately after a MySQL restart. Once OpenSIPS is restarted after a crash, everything runs fine until next MySQL restart.

The log shows:

"opensips[16769]: segfault at 4c8 ip 7f36728bf283 sp 7fff7ba11a90 error 4 in libmysqlclient.so.15.0.0[7f3672862000+1bf000]"
 
and gdb bt gives following results:

---------------
Program terminated with signal 11, Segmentation fault.
[New process 16769]
#0  0x00007f36728bf283 in mysql_stmt_result_metadata ()
   from /usr/lib/libmysqlclient.so.15
(gdb) bt
#0  0x00007f36728bf283 in mysql_stmt_result_metadata ()
   from /usr/lib/libmysqlclient.so.15
#1  0x00007f3672c707b7 in db_mysql_do_prepared_query (conn=0x78b278, 
    query=<value optimized out>, v=0x7fff7ba11d20, n=1, uv=0x0, un=0)
    at dbase.c:363
#2  0x00007f3672c72e1f in db_mysql_query (_h=0x78b278, 
    _k=<value optimized out>, _op=<value optimized out>, _v=0x7fff7ba11d20, 
    _c=<value optimized out>, _n=1, _nc=2, _o=0x0, _r=0x7fff7ba11dc0)
    at dbase.c:591
#3  0x00007f366f3f0398 in authorize (_m=0x78fe98, 
    _realm=<value optimized out>, _table=<value optimized out>, 
    _hftype=<value optimized out>) at authorize.c:107
#4  0x000000000040f869 in do_action (a=0x780a48, msg=0x78fe98) at action.c:961
#5  0x000000000040e7e5 in run_action_list (a=<value optimized out>, 
    msg=0x78fe98) at action.c:139
#6  0x000000000046f194 in eval_elem (e=0x780b18, msg=0x78fe98, val=0x0)
    at route.c:1189
#7  0x00000000004708ed in eval_expr (e=0x120b1e0, msg=0x78fe98, val=0x0)
    at route.c:1486
#8  0x000000000047089c in eval_expr (e=0x780b60, msg=0x78fe98, val=0x0)
    at route.c:1502
#9  0x00000000004708c5 in eval_expr (e=0x780ba8, msg=0x78fe98, val=0x0)
    at route.c:1507
---Type <return> to continue, or q <return> to quit---
#10 0x000000000040f91c in do_action (a=0x780f40, msg=0x78fe98) at action.c:688
#11 0x000000000040e7e5 in run_action_list (a=<value optimized out>, 
    msg=0x78fe98) at action.c:139
#12 0x00000000004114d3 in do_action (a=0x781eb0, msg=0x78fe98) at action.c:705
#13 0x000000000040e7e5 in run_action_list (a=<value optimized out>, 
    msg=0x78fe98) at action.c:139
#14 0x0000000000410e07 in do_action (a=0x77ee88, msg=0x78fe98) at action.c:119
#15 0x000000000040e7e5 in run_action_list (a=<value optimized out>, 
    msg=0x78fe98) at action.c:139
#16 0x00000000004114d3 in do_action (a=0x77f028, msg=0x78fe98) at action.c:705
#17 0x000000000040e7e5 in run_action_list (a=<value optimized out>, 
    msg=0x78fe98) at action.c:139
#18 0x00000000004125fe in run_top_route (a=0x777e78, msg=0x78fe98)
    at action.c:119
#19 0x000000000045e898 in receive_msg (
    buf=0x749180 "REGISTER sip:x.x.x.x SIP/2.0\r\nCSeq: 2 REGISTER\r\nVia: SIP/2.0/UDP x.x.x.x:5061;branch=z9hG4bK60f1b2dd-57fa-dd11-9401-0015c5404858;rport\r\nUser-Agent: Ekiga/2.0.12\r\nAuthorization: Dige"..., 
    len=749, rcv_info=0x7fff7ba13530) at receive.c:165
#20 0x000000000049d3a6 in udp_rcv_loop () at udp_server.c:449
#21 0x00000000004291fb in main (argc=<value optimized out>, 
    argv=0x7fff7ba13718) at main.c:778
----------------


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

Comment By: I?aki Baz (ibc_sf)
Date: 2009-02-20 11:46

Message:
My OpenSIPS rev-5351 crahses daily without restarting MySQL (Debian Etch 64
bits). Simple backtrace:

#0  0x00002b1cd7475a92 in mysql_stmt_result_metadata () from
/usr/lib/libmysqlclient.so.15
#1  0x00002b1cd730023c in db_mysql_free_result () from
/usr/lib/opensips/modules/db_mysql.so
#2  0x00002b1cd73013b6 in db_mysql_query () from
/usr/lib/opensips/modules/db_mysql.so
#3  0x00002b1cd859b8f8 in ?? () from /usr/lib/opensips/modules/auth_db.so
#4  0x000000000040f894 in do_action ()
#5  0x000000000040e0f3 in run_action_list ()
#6  0x000000000044c957 in eval_expr ()
#7  0x000000000044c3d0 in eval_expr ()
#8  0x000000000044c34f in eval_expr ()
#9  0x000000000040f939 in do_action ()
#10 0x000000000040e0f3 in run_action_list ()
#11 0x000000000041093a in do_action ()
#12 0x000000000040e0f3 in run_action_list ()
#13 0x000000000041176f in do_action ()
#14 0x000000000040e0f3 in run_action_list ()
#15 0x000000000040e480 in run_top_route ()
#16 0x0000000000441b4c in receive_msg ()
#17 0x0000000000464bfd in tcp_read_req ()
#18 0x000000000046691e in tcp_read_req ()
#19 0x0000000000468114 in tcp_receive_loop ()
#20 0x000000000045b83d in tcp_init_children ()
#21 0x000000000042368e in main ()


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

Comment By: Nobody/Anonymous (nobody)
Date: 2009-02-19 07:56

Message:
Hi Bogdan,

The issue remains with latest SVN also.

Here is the gdb trace now:

#0  0x00007f0119426283 in mysql_stmt_result_metadata () from
/usr/lib/libmysqlclient.so.15
(gdb) bt
#0  0x00007f0119426283 in mysql_stmt_result_metadata () from
/usr/lib/libmysqlclient.so.15
#1  0x00007f01197d8f82 in db_mysql_do_prepared_query (conn=0x78b278,
query=<value optimized out>, v=0x7fff22576880, n=<value optimized out>,
uv=0x0, un=0)
    at dbase.c:368
#2  0x00007f01197daccd in db_mysql_query (_h=0x78b278, _k=<value optimized
out>, _op=<value optimized out>, _v=0x7fff22576880, _c=<value optimized
out>, 
    _n=1, _nc=2, _o=0x0, _r=0x7fff22576920) at dbase.c:603
#3  0x00007f0115f56398 in authorize (_m=0x78fe98, _realm=<value optimized
out>, _table=<value optimized out>, _hftype=<value optimized out>)
    at authorize.c:107
#4  0x000000000040f869 in do_action (a=0x780a48, msg=0x78fe98) at
action.c:961
#5  0x000000000040e7e5 in run_action_list (a=<value optimized out>,
msg=0x78fe98) at action.c:139
#6  0x000000000046f194 in eval_elem (e=0x780b18, msg=0x78fe98, val=0x0) at
route.c:1189
#7  0x00000000004708ed in eval_expr (e=0x27648e0, msg=0x78fe98, val=0x0)
at route.c:1486
#8  0x000000000047089c in eval_expr (e=0x780b60, msg=0x78fe98, val=0x0) at
route.c:1502
#9  0x00000000004708c5 in eval_expr (e=0x780ba8, msg=0x78fe98, val=0x0) at
route.c:1507
#10 0x000000000040f91c in do_action (a=0x780f40, msg=0x78fe98) at
action.c:688
#11 0x000000000040e7e5 in run_action_list (a=<value optimized out>,
msg=0x78fe98) at action.c:139
#12 0x00000000004114d3 in do_action (a=0x781eb0, msg=0x78fe98) at
action.c:705
#13 0x000000000040e7e5 in run_action_list (a=<value optimized out>,
msg=0x78fe98) at action.c:139
#14 0x0000000000410e07 in do_action (a=0x77ee88, msg=0x78fe98) at
action.c:119
#15 0x000000000040e7e5 in run_action_list (a=<value optimized out>,
msg=0x78fe98) at action.c:139
#16 0x00000000004114d3 in do_action (a=0x77f028, msg=0x78fe98) at
action.c:705
#17 0x000000000040e7e5 in run_action_list (a=<value optimized out>,
msg=0x78fe98) at action.c:139
#18 0x00000000004125fe in run_top_route (a=0x777e78, msg=0x78fe98) at
action.c:119
#19 0x000000000045e898 in receive_msg (
    buf=0x749180 "REGISTER sip:x.x.x.x SIP/2.0\r\nCSeq: 58
REGISTER\r\nVia: SIP/2.0/UDP
x.x.x.x:5068;branch=z9hG4bK5ca4685b-befc-dd11-911f-0015c5404858;rport\r\nUser-Agent:
Ekiga/2.0.12\r\nAuthorization: Dig"..., len=750, rcv_info=0x7fff22578090)
at receive.c:165
#20 0x000000000049d3a6 in udp_rcv_loop () at udp_server.c:449
#21 0x00000000004291fb in main (argc=<value optimized out>,
argv=0x7fff22578278) at main.c:778


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

Comment By: Nobody/Anonymous (nobody)
Date: 2009-02-19 07:52

Message:
Hi Bogdan,

The issue remains with latest SVN also.

Here is the gdb trace now:

#0  0x00007f0119426283 in mysql_stmt_result_metadata () from
/usr/lib/libmysqlclient.so.15
(gdb) bt
#0  0x00007f0119426283 in mysql_stmt_result_metadata () from
/usr/lib/libmysqlclient.so.15
#1  0x00007f01197d8f82 in db_mysql_do_prepared_query (conn=0x78b278,
query=<value optimized out>, v=0x7fff22576880, n=<value optimized out>,
uv=0x0, un=0)
    at dbase.c:368
#2  0x00007f01197daccd in db_mysql_query (_h=0x78b278, _k=<value optimized
out>, _op=<value optimized out>, _v=0x7fff22576880, _c=<value optimized
out>, 
    _n=1, _nc=2, _o=0x0, _r=0x7fff22576920) at dbase.c:603
#3  0x00007f0115f56398 in authorize (_m=0x78fe98, _realm=<value optimized
out>, _table=<value optimized out>, _hftype=<value optimized out>)
    at authorize.c:107
#4  0x000000000040f869 in do_action (a=0x780a48, msg=0x78fe98) at
action.c:961
#5  0x000000000040e7e5 in run_action_list (a=<value optimized out>,
msg=0x78fe98) at action.c:139
#6  0x000000000046f194 in eval_elem (e=0x780b18, msg=0x78fe98, val=0x0) at
route.c:1189
#7  0x00000000004708ed in eval_expr (e=0x27648e0, msg=0x78fe98, val=0x0)
at route.c:1486
#8  0x000000000047089c in eval_expr (e=0x780b60, msg=0x78fe98, val=0x0) at
route.c:1502
#9  0x00000000004708c5 in eval_expr (e=0x780ba8, msg=0x78fe98, val=0x0) at
route.c:1507
#10 0x000000000040f91c in do_action (a=0x780f40, msg=0x78fe98) at
action.c:688
#11 0x000000000040e7e5 in run_action_list (a=<value optimized out>,
msg=0x78fe98) at action.c:139
#12 0x00000000004114d3 in do_action (a=0x781eb0, msg=0x78fe98) at
action.c:705
#13 0x000000000040e7e5 in run_action_list (a=<value optimized out>,
msg=0x78fe98) at action.c:139
#14 0x0000000000410e07 in do_action (a=0x77ee88, msg=0x78fe98) at
action.c:119
#15 0x000000000040e7e5 in run_action_list (a=<value optimized out>,
msg=0x78fe98) at action.c:139
#16 0x00000000004114d3 in do_action (a=0x77f028, msg=0x78fe98) at
action.c:705
#17 0x000000000040e7e5 in run_action_list (a=<value optimized out>,
msg=0x78fe98) at action.c:139
#18 0x00000000004125fe in run_top_route (a=0x777e78, msg=0x78fe98) at
action.c:119
#19 0x000000000045e898 in receive_msg (
    buf=0x749180 "REGISTER sip:x.x.x.x SIP/2.0\r\nCSeq: 58
REGISTER\r\nVia: SIP/2.0/UDP
x.x.x.x:5068;branch=z9hG4bK5ca4685b-befc-dd11-911f-0015c5404858;rport\r\nUser-Agent:
Ekiga/2.0.12\r\nAuthorization: Dig"..., len=750, rcv_info=0x7fff22578090)
at receive.c:165
#20 0x000000000049d3a6 in udp_rcv_loop () at udp_server.c:449
#21 0x00000000004291fb in main (argc=<value optimized out>,
argv=0x7fff22578278) at main.c:778


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

Comment By: Bogdan-Andrei Iancu (bogdan_iancu)
Date: 2009-02-18 22:02

Message:
Hi Om,

I hopefully fixed the problem - please update from SVN and give it another
try. Let me know if now works.

Thanks and regards,
Bogdan

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

Comment By: Om Bikram Thapa (omthapa)
Date: 2009-02-18 14:11

Message:
I modified domain in opensips domain table, immediately after that the
server crashed upon registration event with log  general protection
ip:7f249016986c sp:7fff992bf320 error:0 in
libmysqlclient.so.15.0.0[7f2490110000+1bf000]" and gdb backtrace now points
to different code:

----------
#0  0x00007f7a4c26f86c in mysql_stmt_fetch () from
/usr/lib/libmysqlclient.so.15
#1  0x00007f7a4c628a48 in db_mysql_convert_result (_h=0x78b278,
_r=0x78ba28) at res.c:161
#2  0x00007f7a4c626aaa in db_mysql_store_result (_h=0x78b278,
_r=0x7fff553c5770) at dbase.c:513
#3  0x00007f7a4c626e39 in db_mysql_query (_h=0x78b278, _k=<value optimized
out>, _op=<value optimized out>, _v=0x7fff553c56d0, _c=<value optimized
out>,
    _n=1, _nc=2, _o=0x0, _r=0x7fff553c5770) at dbase.c:593
#4  0x00007f7a48da4398 in authorize (_m=0x78fe98, _realm=<value optimized
out>, _table=<value optimized out>, _hftype=<value optimized out>)
    at authorize.c:107
#5  0x000000000040f869 in do_action (a=0x780a48, msg=0x78fe98) at
action.c:961
#6  0x000000000040e7e5 in run_action_list (a=<value optimized out>,
msg=0x78fe98) at action.c:139
#7  0x000000000046f194 in eval_elem (e=0x780b18, msg=0x78fe98, val=0x20)
at route.c:1189
#8  0x00000000004708ed in eval_expr (e=0xe543d0, msg=0x78fe98, val=0x0) at
route.c:1486
#9  0x000000000047089c in eval_expr (e=0x780b60, msg=0x78fe98, val=0x0) at
route.c:1502
#10 0x00000000004708c5 in eval_expr (e=0x780ba8, msg=0x78fe98, val=0x0) at
route.c:1507
#11 0x000000000040f91c in do_action (a=0x780f40, msg=0x78fe98) at
action.c:688
#12 0x000000000040e7e5 in run_action_list (a=<value optimized out>,
msg=0x78fe98) at action.c:139
#13 0x00000000004114d3 in do_action (a=0x781eb0, msg=0x78fe98) at
action.c:705
#14 0x000000000040e7e5 in run_action_list (a=<value optimized out>,
msg=0x78fe98) at action.c:139
#15 0x0000000000410e07 in do_action (a=0x77ee88, msg=0x78fe98) at
action.c:119
#16 0x000000000040e7e5 in run_action_list (a=<value optimized out>,
msg=0x78fe98) at action.c:139
#17 0x00000000004114d3 in do_action (a=0x77f028, msg=0x78fe98) at
action.c:705
#18 0x000000000040e7e5 in run_action_list (a=<value optimized out>,
msg=0x78fe98) at action.c:139
#19 0x00000000004125fe in run_top_route (a=0x777e78, msg=0x78fe98) at
action.c:119
#20 0x000000000045e898 in receive_msg (
    buf=0x749180 "REGISTER sip:x.x.x.x;transport=UDP SIP/2.0\r\nVia:
SIP/2.0/UDP
x.x.x.x:5060;branch=z9hG4bKgcjsr9edklicvlhif2tfvub;rport\r\nFrom:
<sip:300000 at x.x."..., len=693, rcv_info=0x7fff553c6ee0) at receive.c:165
#21 0x000000000049d3a6 in udp_rcv_loop () at udp_server.c:449
#22 0x00000000004291fb in main (argc=<value optimized out>,
argv=0x7fff553c70c8) at main.c:778
-----------------

I think this crash is also related to the same issue.

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

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


From noreply at sourceforge.net  Fri Feb 20 13:09:15 2009
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 20 Feb 2009 12:09:15 +0000
Subject: [OpenSIPS-Devel] [ opensips-Bugs-2523454 ] Error in handling rls
	NOTIFY
Message-ID: <E1LaUBv-0007JO-Tg@h45xhf1.ch3.sourceforge.com>

Bugs item #2523454, was opened at 2009-01-20 13:55
Message generated for change (Comment added) made by anca_vamanu
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=2523454&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: Nathan (rmnathan)
Assigned to: Anca Vamanu (anca_vamanu)
Summary: Error in handling rls NOTIFY

Initial Comment:
Hi
The following error message are printed while handling rls notify.
Jan 20 06:45:44 [7833] ERROR:rls:parse_subs_state: terminated state and no reason foundJan 20 06:45:44 [7833] ERROR:rls:rls_handle_notify: while parsing 'Subscription-State' header
Jan 20 06:45:44 [7833] ERROR:rls:parse_subs_state: terminated state and no reason foundJan 20 06:45:44 [7833] ERROR:rls:rls_handle_notify: while parsing 'Subscription-State' header
Jan 20 06:45:44 [7833] ERROR:rls:parse_subs_state: terminated state and no reason foundJan 20 06:45:44 [7833] ERROR:rls:rls_handle_notify: while parsing 'Subscription-State' header
Jan 20 06:45:52 [7833] ERROR:rls:parse_subs_state: terminated state and no reason foundJan 20 06:45:52 [7833] ERROR:rls:rls_handle_notify: while parsing 'Subscription-State' header
Jan 20 06:45:52 [7833] ERROR:rls:parse_subs_state: terminated state and no reason foundJan 20 06:45:52 [7833] ERROR:rls:rls_handle_notify: while parsing 'Subscription-State' header
Jan 20 06:46:13 [7834] ERROR:core:db_do_insert: invalid parameter value
Jan 20 06:46:13 [7834] ERROR:pua:db_update: while inserting in db table pua
Jan 20 06:46:43 [7834] ERROR:core:parse_uri: uri too short: <> (0)
Jan 20 06:46:43 [7834] ERROR:tm:uri2proxy: bad_uri:
Jan 20 06:46:43 [7834] ERROR:tm:uri2su: failed create a dst proxy
Jan 20 06:46:43 [7834] ERROR:tm:t_uac: no socket found
Jan 20 06:46:43 [7834] ERROR:pua:update_pua: in t_request function
Jan 20 06:46:43 [7834] ERROR:pua:hashT_clean: while updating record
Jan 20 06:47:05 [7833] ERROR:rls:parse_subs_state: terminated state and no reason foundJan 20 06:47:05 [7833] ERROR:rls:rls_handle_notify: while parsing 'Subscription-State' header

Regards,
rmnathan


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

>Comment By: Anca Vamanu (anca_vamanu)
Date: 2009-02-20 14:09

Message:
Hi,

Can you tell me also what's running at 192.168.166.150:50607? 

thanks,
Anca

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

Comment By: Nathan (rmnathan)
Date: 2009-02-20 12:28

Message:
Hi Anca,
You are correct . That is not presence or rls server. It is registrar
(scscf) running on 192.168.166.150:50606. 
Please let me know if you want any information.

Thanks lot
rmnathan

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

Comment By: Anca Vamanu (anca_vamanu)
Date: 2009-02-19 14:03

Message:
Hi Rmnathan,

I looked through your trace but something is confusing.
Can you please tell me what was running on 192.168.166.150 port 50606. I
see that the User-Agent header is OpenSIPS, but the behavior doesn't seem
like that of a presence or rls server.

regards,
Anca

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

Comment By: Nathan (rmnathan)
Date: 2009-02-02 11:14

Message:
Hi Anca.
Yes, am using opensips as presence server and rls server. Please find the
logs and pcap file for call flow attached.

Regards,
rmnathan


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

Comment By: Anca Vamanu (anca_vamanu)
Date: 2009-01-22 15:25

Message:
Hi rmnathan,

Thank you for this report also.
There is something wrong with that Notify that gives this error.
Can you please trace the trafic and catch a Notify that generates this
error and print it here?
This Notify is received from the presence server. Are you using also
OpenSIPS as the presence server? Can you please check is the source IP
address of the Notify message is that of the presence server?

regards,
Anca

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

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


From noreply at sourceforge.net  Fri Feb 20 13:25:00 2009
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 20 Feb 2009 12:25:00 +0000
Subject: [OpenSIPS-Devel] [ opensips-Bugs-2538399 ] Bug in presence when
	using fallback2db
Message-ID: <E1LaURA-0006xk-VW@565xhf1.ch3.sourceforge.com>

Bugs item #2538399, was opened at 2009-01-26 21:39
Message generated for change (Comment added) made by anca_vamanu
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=2538399&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: Oren K (oren_k)
Assigned to: Anca Vamanu (anca_vamanu)
Summary: Bug in presence when using fallback2db

Initial Comment:
Hi,

While using the presence module, I run this scenario:

a. user1 SUBSCRIBE's to presence of user2
(subscription is now pending)

b. user2 allows user1 in pres-rules
(refreshWatchers is called, subscription is now active. user1 receives a NOTIFY from presence server with user2's current tuple and Subscription-State: active)

c. user2 PUBLISH'es a new presence tuple
-- at this point presence server should NOTIFY user1 of the new presence but it doesn't (that's the bug).


My modparams:

modparam("presence|presence_xml", "db_url", "mysql://root at localhost/opensips")

modparam("presence", "server_address", "sip:presence.example.com:10500")

modparam("presence", "fallback2db", 1)
modparam("presence", "clean_period", 30)


What I see in the debug trace is that get_subs_dialog (from notify.c) can't find any dialogs in the database, and all those in the subs hash are flagged NO_UPDATEDB_FLAG. This is probably what's causing the problem. 
Strangely, in the above scenario if user1 un-SUBSCRIBEs and re-SUBSCRIBEs to user2's presence - it does receive notifications.

Regards,
Oren K.

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

>Comment By: Anca Vamanu (anca_vamanu)
Date: 2009-02-20 14:25

Message:
Hi Oren,

I have looked into the log file that you posted and saw that there was and
error there. There is a problem with the body of the Publish message -
which causes stopping the processing. The problem is that the code in the
presence server expects a tuple element in the body - and the body of the
last Publish message does not contain one.
I have looked up in the RFC and saw that the tuple element is in fact not
compulsory - so there is a bug in the presence code - but not the one you
reported :). 
I will fix this soon.

Thanks and regards,
Anca

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

Comment By: Oren K (oren_k)
Date: 2009-02-20 01:42

Message:
Still no joy.. adding updated log and pcap for the version i compiled from
svn 1.5.0dev5-tls.

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

Comment By: Anca Vamanu (anca_vamanu)
Date: 2009-02-18 18:11

Message:
Hi, 

I have just now made some changes in presence module for fallback2db case.
Can you please update to the newest svn version for 1.5 and test again?

regards,
Anca

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

Comment By: Anca Vamanu (anca_vamanu)
Date: 2009-02-18 18:10

Message:
Hi, 

I have just now made some changes in presence module for fallback2db case.
Can you please update to the newest svn version for 1.5 and test again?

regards,
Anca

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

Comment By: Oren K (oren_k)
Date: 2009-02-07 02:23

Message:
Hi Anca,

I've attached a debug-log and wireshark pcap file to the post. The pcap
file also contains the XCAP PUTs to change the presence rules. The only
error in the log comes from presence_xml not being able to extract a tuple
node because our client uses <pdm:person> for the presence (Same bug
happened to us when we tried with <tuple> so that's not the issue). The
things that strike me odd in presence_bug.log are:

(after step b. user2 allows user1 in pres-rules)
line 634: DBG:presence:update_pw_dialogs: found 1 matching dialogs

the module finds the watcher dialog and updates it due to refreshWatchers.
user1 receives a NOTIFY with Subscription-State:active. Now step c. user2
PUBLISH'es a new presence tuple:

line 919: DBG:core:parse_msg:  method:  <PUBLISH>

everything looks okay BUT:

line 1087: DBG:presence:get_subs_db: The query for subscribtion for [uri]=
sip:user2 at openims.summit-tech.ca for [event]= presence returned no result
line 1110: DBG:presence:get_subs_dialog: s->db_flag== UPDATEDB_FLAG
line 1111: DBG:presence:get_subs_dialog: found 0 dialogs( 0 in database
and 0 in hash_table)
line 1112: DBG:presence:publ_notify: Could not find subs_dialog

..suddenly there are no subscribers?

Thanks.


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

Comment By: Anca Vamanu (anca_vamanu)
Date: 2009-02-06 20:14

Message:
Hi Oren,

I have just downloaded myself the release and tested and the scenario that
you described works. 
Do you notice any error in your log file?

regards,
Anca

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

Comment By: Oren K (oren_k)
Date: 2009-02-01 18:41

Message:
Sorry I forgot to login, that comment is from me :)

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

Comment By: Nobody/Anonymous (nobody)
Date: 2009-01-28 17:12

Message:
Thanks for the reply anca. Version is opensips-1.4.4-tls, compiled from the
sources with TLS="1". 

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

Comment By: Anca Vamanu (anca_vamanu)
Date: 2009-01-28 13:48

Message:
Hi Oren,

What OpenSIPS version are you using? Trunk or stable release?

regards,
Anca

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

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


From anca at opensips.org  Fri Feb 20 13:58:47 2009
From: anca at opensips.org (Anca Vamanu)
Date: Fri, 20 Feb 2009 12:58:47 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[5352]
	trunk/modules/presence_xml/notify_body.c
Message-ID: <E1LaUxr-0003NV-DI@bj8yhf1.ch3.sourceforge.com>

Revision: 5352
          http://opensips.svn.sourceforge.net/opensips/?rev=5352&view=rev
Author:   anca_vamanu
Date:     2009-02-20 12:58:47 +0000 (Fri, 20 Feb 2009)

Log Message:
-----------
- fix: removed considering the 'tuple' element in application/pidf+xml documents compulsory
	( thanks to Oren K. who helped descovering this)

Modified Paths:
--------------
    trunk/modules/presence_xml/notify_body.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 Feb 20 13:59:13 2009
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 20 Feb 2009 12:59:13 +0000
Subject: [OpenSIPS-Devel] [ opensips-Bugs-2538399 ] Bug in presence when
	using fallback2db
Message-ID: <E1LaUyH-00025q-NL@665xhf1.ch3.sourceforge.com>

Bugs item #2538399, was opened at 2009-01-26 21:39
Message generated for change (Comment added) made by anca_vamanu
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=2538399&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: Oren K (oren_k)
Assigned to: Anca Vamanu (anca_vamanu)
Summary: Bug in presence when using fallback2db

Initial Comment:
Hi,

While using the presence module, I run this scenario:

a. user1 SUBSCRIBE's to presence of user2
(subscription is now pending)

b. user2 allows user1 in pres-rules
(refreshWatchers is called, subscription is now active. user1 receives a NOTIFY from presence server with user2's current tuple and Subscription-State: active)

c. user2 PUBLISH'es a new presence tuple
-- at this point presence server should NOTIFY user1 of the new presence but it doesn't (that's the bug).


My modparams:

modparam("presence|presence_xml", "db_url", "mysql://root at localhost/opensips")

modparam("presence", "server_address", "sip:presence.example.com:10500")

modparam("presence", "fallback2db", 1)
modparam("presence", "clean_period", 30)


What I see in the debug trace is that get_subs_dialog (from notify.c) can't find any dialogs in the database, and all those in the subs hash are flagged NO_UPDATEDB_FLAG. This is probably what's causing the problem. 
Strangely, in the above scenario if user1 un-SUBSCRIBEs and re-SUBSCRIBEs to user2's presence - it does receive notifications.

Regards,
Oren K.

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

>Comment By: Anca Vamanu (anca_vamanu)
Date: 2009-02-20 14:59

Message:
Hi,

I have just made a fix. Please update, test again and reply.

Thanks,
Anca

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

Comment By: Anca Vamanu (anca_vamanu)
Date: 2009-02-20 14:25

Message:
Hi Oren,

I have looked into the log file that you posted and saw that there was and
error there. There is a problem with the body of the Publish message -
which causes stopping the processing. The problem is that the code in the
presence server expects a tuple element in the body - and the body of the
last Publish message does not contain one.
I have looked up in the RFC and saw that the tuple element is in fact not
compulsory - so there is a bug in the presence code - but not the one you
reported :). 
I will fix this soon.

Thanks and regards,
Anca

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

Comment By: Oren K (oren_k)
Date: 2009-02-20 01:42

Message:
Still no joy.. adding updated log and pcap for the version i compiled from
svn 1.5.0dev5-tls.

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

Comment By: Anca Vamanu (anca_vamanu)
Date: 2009-02-18 18:11

Message:
Hi, 

I have just now made some changes in presence module for fallback2db case.
Can you please update to the newest svn version for 1.5 and test again?

regards,
Anca

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

Comment By: Anca Vamanu (anca_vamanu)
Date: 2009-02-18 18:10

Message:
Hi, 

I have just now made some changes in presence module for fallback2db case.
Can you please update to the newest svn version for 1.5 and test again?

regards,
Anca

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

Comment By: Oren K (oren_k)
Date: 2009-02-07 02:23

Message:
Hi Anca,

I've attached a debug-log and wireshark pcap file to the post. The pcap
file also contains the XCAP PUTs to change the presence rules. The only
error in the log comes from presence_xml not being able to extract a tuple
node because our client uses <pdm:person> for the presence (Same bug
happened to us when we tried with <tuple> so that's not the issue). The
things that strike me odd in presence_bug.log are:

(after step b. user2 allows user1 in pres-rules)
line 634: DBG:presence:update_pw_dialogs: found 1 matching dialogs

the module finds the watcher dialog and updates it due to refreshWatchers.
user1 receives a NOTIFY with Subscription-State:active. Now step c. user2
PUBLISH'es a new presence tuple:

line 919: DBG:core:parse_msg:  method:  <PUBLISH>

everything looks okay BUT:

line 1087: DBG:presence:get_subs_db: The query for subscribtion for [uri]=
sip:user2 at openims.summit-tech.ca for [event]= presence returned no result
line 1110: DBG:presence:get_subs_dialog: s->db_flag== UPDATEDB_FLAG
line 1111: DBG:presence:get_subs_dialog: found 0 dialogs( 0 in database
and 0 in hash_table)
line 1112: DBG:presence:publ_notify: Could not find subs_dialog

..suddenly there are no subscribers?

Thanks.


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

Comment By: Anca Vamanu (anca_vamanu)
Date: 2009-02-06 20:14

Message:
Hi Oren,

I have just downloaded myself the release and tested and the scenario that
you described works. 
Do you notice any error in your log file?

regards,
Anca

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

Comment By: Oren K (oren_k)
Date: 2009-02-01 18:41

Message:
Sorry I forgot to login, that comment is from me :)

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

Comment By: Nobody/Anonymous (nobody)
Date: 2009-01-28 17:12

Message:
Thanks for the reply anca. Version is opensips-1.4.4-tls, compiled from the
sources with TLS="1". 

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

Comment By: Anca Vamanu (anca_vamanu)
Date: 2009-01-28 13:48

Message:
Hi Oren,

What OpenSIPS version are you using? Trunk or stable release?

regards,
Anca

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

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


From noreply at sourceforge.net  Fri Feb 20 19:22:44 2009
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 20 Feb 2009 18:22:44 +0000
Subject: [OpenSIPS-Devel] [ opensips-Bugs-2538399 ] Bug in presence when
	using fallback2db
Message-ID: <E1Laa1M-0001pP-GT@b55xhf1.ch3.sourceforge.com>

Bugs item #2538399, was opened at 2009-01-26 14:39
Message generated for change (Comment added) made by oren_k
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=2538399&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: Oren K (oren_k)
Assigned to: Anca Vamanu (anca_vamanu)
Summary: Bug in presence when using fallback2db

Initial Comment:
Hi,

While using the presence module, I run this scenario:

a. user1 SUBSCRIBE's to presence of user2
(subscription is now pending)

b. user2 allows user1 in pres-rules
(refreshWatchers is called, subscription is now active. user1 receives a NOTIFY from presence server with user2's current tuple and Subscription-State: active)

c. user2 PUBLISH'es a new presence tuple
-- at this point presence server should NOTIFY user1 of the new presence but it doesn't (that's the bug).


My modparams:

modparam("presence|presence_xml", "db_url", "mysql://root at localhost/opensips")

modparam("presence", "server_address", "sip:presence.example.com:10500")

modparam("presence", "fallback2db", 1)
modparam("presence", "clean_period", 30)


What I see in the debug trace is that get_subs_dialog (from notify.c) can't find any dialogs in the database, and all those in the subs hash are flagged NO_UPDATEDB_FLAG. This is probably what's causing the problem. 
Strangely, in the above scenario if user1 un-SUBSCRIBEs and re-SUBSCRIBEs to user2's presence - it does receive notifications.

Regards,
Oren K.

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

Comment By: Oren K (oren_k)
Date: 2009-02-20 13:22

Message:
Something else is wrong now. mi_refresh_watchers is getting a timeout. This
didn't happen before. I'm using:
OpenXCAP 1.0.6
opensips-mi-proxy 1.0.2

Right now nothing works, not even normal scenarios.

Feb 20 13:16:22 openims opensips-mi-proxy[2368]: [-] error: Error while
processing command refreshWatchers (sip:user2 at openims.summit-tech.ca
presence 0): O
penSIPS command did timeout
Feb 20 13:16:22 openims opensips-mi-proxy[2368]: [-] Exception rendering:
Feb 20 13:16:22 openims opensips-mi-proxy[2368]: [-] Traceback (most
recent call last):
Feb 20 13:16:22 openims opensips-mi-proxy[2368]: [-]       File
"/usr/lib/python2.5/site-packages/Twisted-8.2.0_r25964-py2.5-linux-i686.egg/twisted/interne
t/defer.py", line 312, in _startRunCallbacks
Feb 20 13:16:22 openims opensips-mi-proxy[2368]: [-]        
self._runCallbacks()
Feb 20 13:16:22 openims opensips-mi-proxy[2368]: [-]       File
"/usr/lib/python2.5/site-packages/Twisted-8.2.0_r25964-py2.5-linux-i686.egg/twisted/interne
t/defer.py", line 328, in _runCallbacks
Feb 20 13:16:22 openims opensips-mi-proxy[2368]: [-]         self.result =
callback(self.result, *args, **kw)
Feb 20 13:16:22 openims opensips-mi-proxy[2368]: [-]       File
"/usr/lib/python2.5/site-packages/Twisted-8.2.0_r25964-py2.5-linux-i686.egg/twisted/interne
t/defer.py", line 289, in _continue
Feb 20 13:16:22 openims opensips-mi-proxy[2368]: [-]        
self.unpause()
Feb 20 13:16:22 openims opensips-mi-proxy[2368]: [-]       File
"/usr/lib/python2.5/site-packages/Twisted-8.2.0_r25964-py2.5-linux-i686.egg/twisted/interne
t/defer.py", line 285, in unpause
Feb 20 13:16:22 openims opensips-mi-proxy[2368]: [-]        
self._runCallbacks()
Feb 20 13:16:22 openims opensips-mi-proxy[2368]: [-]     --- <exception
caught here> ---
Feb 20 13:16:22 openims opensips-mi-proxy[2368]: [-]       File
"/usr/lib/python2.5/site-packages/Twisted-8.2.0_r25964-py2.5-linux-i686.egg/twisted/interne
t/defer.py", line 328, in _runCallbacks
Feb 20 13:16:22 openims opensips-mi-proxy[2368]: [-]         self.result =
callback(self.result, *args, **kw)
Feb 20 13:16:22 openims opensips-mi-proxy[2368]: [-]       File
"/usr/lib/python2.5/site-packages/miproxy/proxy.py", line 89, in _cbRender
Feb 20 13:16:22 openims opensips-mi-proxy[2368]: [-]         code =
int(code)
Feb 20 13:16:22 openims opensips-mi-proxy[2368]: [-]    
exceptions.ValueError: invalid literal for int() with base 10: 'OpenSIPS'


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

Comment By: Anca Vamanu (anca_vamanu)
Date: 2009-02-20 07:59

Message:
Hi,

I have just made a fix. Please update, test again and reply.

Thanks,
Anca

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

Comment By: Anca Vamanu (anca_vamanu)
Date: 2009-02-20 07:25

Message:
Hi Oren,

I have looked into the log file that you posted and saw that there was and
error there. There is a problem with the body of the Publish message -
which causes stopping the processing. The problem is that the code in the
presence server expects a tuple element in the body - and the body of the
last Publish message does not contain one.
I have looked up in the RFC and saw that the tuple element is in fact not
compulsory - so there is a bug in the presence code - but not the one you
reported :). 
I will fix this soon.

Thanks and regards,
Anca

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

Comment By: Oren K (oren_k)
Date: 2009-02-19 18:42

Message:
Still no joy.. adding updated log and pcap for the version i compiled from
svn 1.5.0dev5-tls.

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

Comment By: Anca Vamanu (anca_vamanu)
Date: 2009-02-18 11:11

Message:
Hi, 

I have just now made some changes in presence module for fallback2db case.
Can you please update to the newest svn version for 1.5 and test again?

regards,
Anca

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

Comment By: Anca Vamanu (anca_vamanu)
Date: 2009-02-18 11:10

Message:
Hi, 

I have just now made some changes in presence module for fallback2db case.
Can you please update to the newest svn version for 1.5 and test again?

regards,
Anca

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

Comment By: Oren K (oren_k)
Date: 2009-02-06 19:23

Message:
Hi Anca,

I've attached a debug-log and wireshark pcap file to the post. The pcap
file also contains the XCAP PUTs to change the presence rules. The only
error in the log comes from presence_xml not being able to extract a tuple
node because our client uses <pdm:person> for the presence (Same bug
happened to us when we tried with <tuple> so that's not the issue). The
things that strike me odd in presence_bug.log are:

(after step b. user2 allows user1 in pres-rules)
line 634: DBG:presence:update_pw_dialogs: found 1 matching dialogs

the module finds the watcher dialog and updates it due to refreshWatchers.
user1 receives a NOTIFY with Subscription-State:active. Now step c. user2
PUBLISH'es a new presence tuple:

line 919: DBG:core:parse_msg:  method:  <PUBLISH>

everything looks okay BUT:

line 1087: DBG:presence:get_subs_db: The query for subscribtion for [uri]=
sip:user2 at openims.summit-tech.ca for [event]= presence returned no result
line 1110: DBG:presence:get_subs_dialog: s->db_flag== UPDATEDB_FLAG
line 1111: DBG:presence:get_subs_dialog: found 0 dialogs( 0 in database
and 0 in hash_table)
line 1112: DBG:presence:publ_notify: Could not find subs_dialog

..suddenly there are no subscribers?

Thanks.


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

Comment By: Anca Vamanu (anca_vamanu)
Date: 2009-02-06 13:14

Message:
Hi Oren,

I have just downloaded myself the release and tested and the scenario that
you described works. 
Do you notice any error in your log file?

regards,
Anca

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

Comment By: Oren K (oren_k)
Date: 2009-02-01 11:41

Message:
Sorry I forgot to login, that comment is from me :)

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

Comment By: Nobody/Anonymous (nobody)
Date: 2009-01-28 10:12

Message:
Thanks for the reply anca. Version is opensips-1.4.4-tls, compiled from the
sources with TLS="1". 

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

Comment By: Anca Vamanu (anca_vamanu)
Date: 2009-01-28 06:48

Message:
Hi Oren,

What OpenSIPS version are you using? Trunk or stable release?

regards,
Anca

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

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


From noreply at sourceforge.net  Fri Feb 20 19:53:56 2009
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 20 Feb 2009 18:53:56 +0000
Subject: [OpenSIPS-Devel] [ opensips-Bugs-2538399 ] Bug in presence when
	using fallback2db
Message-ID: <E1LaaVY-0002Cu-D2@d45xhf1.ch3.sourceforge.com>

Bugs item #2538399, was opened at 2009-01-26 14:39
Message generated for change (Comment added) made by oren_k
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=2538399&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: Oren K (oren_k)
Assigned to: Anca Vamanu (anca_vamanu)
Summary: Bug in presence when using fallback2db

Initial Comment:
Hi,

While using the presence module, I run this scenario:

a. user1 SUBSCRIBE's to presence of user2
(subscription is now pending)

b. user2 allows user1 in pres-rules
(refreshWatchers is called, subscription is now active. user1 receives a NOTIFY from presence server with user2's current tuple and Subscription-State: active)

c. user2 PUBLISH'es a new presence tuple
-- at this point presence server should NOTIFY user1 of the new presence but it doesn't (that's the bug).


My modparams:

modparam("presence|presence_xml", "db_url", "mysql://root at localhost/opensips")

modparam("presence", "server_address", "sip:presence.example.com:10500")

modparam("presence", "fallback2db", 1)
modparam("presence", "clean_period", 30)


What I see in the debug trace is that get_subs_dialog (from notify.c) can't find any dialogs in the database, and all those in the subs hash are flagged NO_UPDATEDB_FLAG. This is probably what's causing the problem. 
Strangely, in the above scenario if user1 un-SUBSCRIBEs and re-SUBSCRIBEs to user2's presence - it does receive notifications.

Regards,
Oren K.

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

Comment By: Oren K (oren_k)
Date: 2009-02-20 13:53

Message:
also I was getting errors because I didn't have a transformations node. The
common-policy schema states that transformations isn't a must-have, and I
think opensips should treat no transformations node the same as if there
was an empty one.

<xs:element name="transformations" type="cp:extensibleType"
minOccurs="0"/>

However, adding a <transformations/> to my pres-rules had not effect on
this bug (still happens).

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

Comment By: Oren K (oren_k)
Date: 2009-02-20 13:22

Message:
Something else is wrong now. mi_refresh_watchers is getting a timeout. This
didn't happen before. I'm using:
OpenXCAP 1.0.6
opensips-mi-proxy 1.0.2

Right now nothing works, not even normal scenarios.

Feb 20 13:16:22 openims opensips-mi-proxy[2368]: [-] error: Error while
processing command refreshWatchers (sip:user2 at openims.summit-tech.ca
presence 0): O
penSIPS command did timeout
Feb 20 13:16:22 openims opensips-mi-proxy[2368]: [-] Exception rendering:
Feb 20 13:16:22 openims opensips-mi-proxy[2368]: [-] Traceback (most
recent call last):
Feb 20 13:16:22 openims opensips-mi-proxy[2368]: [-]       File
"/usr/lib/python2.5/site-packages/Twisted-8.2.0_r25964-py2.5-linux-i686.egg/twisted/interne
t/defer.py", line 312, in _startRunCallbacks
Feb 20 13:16:22 openims opensips-mi-proxy[2368]: [-]        
self._runCallbacks()
Feb 20 13:16:22 openims opensips-mi-proxy[2368]: [-]       File
"/usr/lib/python2.5/site-packages/Twisted-8.2.0_r25964-py2.5-linux-i686.egg/twisted/interne
t/defer.py", line 328, in _runCallbacks
Feb 20 13:16:22 openims opensips-mi-proxy[2368]: [-]         self.result =
callback(self.result, *args, **kw)
Feb 20 13:16:22 openims opensips-mi-proxy[2368]: [-]       File
"/usr/lib/python2.5/site-packages/Twisted-8.2.0_r25964-py2.5-linux-i686.egg/twisted/interne
t/defer.py", line 289, in _continue
Feb 20 13:16:22 openims opensips-mi-proxy[2368]: [-]        
self.unpause()
Feb 20 13:16:22 openims opensips-mi-proxy[2368]: [-]       File
"/usr/lib/python2.5/site-packages/Twisted-8.2.0_r25964-py2.5-linux-i686.egg/twisted/interne
t/defer.py", line 285, in unpause
Feb 20 13:16:22 openims opensips-mi-proxy[2368]: [-]        
self._runCallbacks()
Feb 20 13:16:22 openims opensips-mi-proxy[2368]: [-]     --- <exception
caught here> ---
Feb 20 13:16:22 openims opensips-mi-proxy[2368]: [-]       File
"/usr/lib/python2.5/site-packages/Twisted-8.2.0_r25964-py2.5-linux-i686.egg/twisted/interne
t/defer.py", line 328, in _runCallbacks
Feb 20 13:16:22 openims opensips-mi-proxy[2368]: [-]         self.result =
callback(self.result, *args, **kw)
Feb 20 13:16:22 openims opensips-mi-proxy[2368]: [-]       File
"/usr/lib/python2.5/site-packages/miproxy/proxy.py", line 89, in _cbRender
Feb 20 13:16:22 openims opensips-mi-proxy[2368]: [-]         code =
int(code)
Feb 20 13:16:22 openims opensips-mi-proxy[2368]: [-]    
exceptions.ValueError: invalid literal for int() with base 10: 'OpenSIPS'


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

Comment By: Anca Vamanu (anca_vamanu)
Date: 2009-02-20 07:59

Message:
Hi,

I have just made a fix. Please update, test again and reply.

Thanks,
Anca

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

Comment By: Anca Vamanu (anca_vamanu)
Date: 2009-02-20 07:25

Message:
Hi Oren,

I have looked into the log file that you posted and saw that there was and
error there. There is a problem with the body of the Publish message -
which causes stopping the processing. The problem is that the code in the
presence server expects a tuple element in the body - and the body of the
last Publish message does not contain one.
I have looked up in the RFC and saw that the tuple element is in fact not
compulsory - so there is a bug in the presence code - but not the one you
reported :). 
I will fix this soon.

Thanks and regards,
Anca

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

Comment By: Oren K (oren_k)
Date: 2009-02-19 18:42

Message:
Still no joy.. adding updated log and pcap for the version i compiled from
svn 1.5.0dev5-tls.

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

Comment By: Anca Vamanu (anca_vamanu)
Date: 2009-02-18 11:11

Message:
Hi, 

I have just now made some changes in presence module for fallback2db case.
Can you please update to the newest svn version for 1.5 and test again?

regards,
Anca

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

Comment By: Anca Vamanu (anca_vamanu)
Date: 2009-02-18 11:10

Message:
Hi, 

I have just now made some changes in presence module for fallback2db case.
Can you please update to the newest svn version for 1.5 and test again?

regards,
Anca

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

Comment By: Oren K (oren_k)
Date: 2009-02-06 19:23

Message:
Hi Anca,

I've attached a debug-log and wireshark pcap file to the post. The pcap
file also contains the XCAP PUTs to change the presence rules. The only
error in the log comes from presence_xml not being able to extract a tuple
node because our client uses <pdm:person> for the presence (Same bug
happened to us when we tried with <tuple> so that's not the issue). The
things that strike me odd in presence_bug.log are:

(after step b. user2 allows user1 in pres-rules)
line 634: DBG:presence:update_pw_dialogs: found 1 matching dialogs

the module finds the watcher dialog and updates it due to refreshWatchers.
user1 receives a NOTIFY with Subscription-State:active. Now step c. user2
PUBLISH'es a new presence tuple:

line 919: DBG:core:parse_msg:  method:  <PUBLISH>

everything looks okay BUT:

line 1087: DBG:presence:get_subs_db: The query for subscribtion for [uri]=
sip:user2 at openims.summit-tech.ca for [event]= presence returned no result
line 1110: DBG:presence:get_subs_dialog: s->db_flag== UPDATEDB_FLAG
line 1111: DBG:presence:get_subs_dialog: found 0 dialogs( 0 in database
and 0 in hash_table)
line 1112: DBG:presence:publ_notify: Could not find subs_dialog

..suddenly there are no subscribers?

Thanks.


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

Comment By: Anca Vamanu (anca_vamanu)
Date: 2009-02-06 13:14

Message:
Hi Oren,

I have just downloaded myself the release and tested and the scenario that
you described works. 
Do you notice any error in your log file?

regards,
Anca

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

Comment By: Oren K (oren_k)
Date: 2009-02-01 11:41

Message:
Sorry I forgot to login, that comment is from me :)

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

Comment By: Nobody/Anonymous (nobody)
Date: 2009-01-28 10:12

Message:
Thanks for the reply anca. Version is opensips-1.4.4-tls, compiled from the
sources with TLS="1". 

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

Comment By: Anca Vamanu (anca_vamanu)
Date: 2009-01-28 06:48

Message:
Hi Oren,

What OpenSIPS version are you using? Trunk or stable release?

regards,
Anca

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

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


From noreply at sourceforge.net  Fri Feb 20 21:37:49 2009
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 20 Feb 2009 20:37:49 +0000
Subject: [OpenSIPS-Devel] [ opensips-Bugs-2608188 ] OpenSIPS latest trunk
	libmysqlclient segfault
Message-ID: <E1Lac85-0002I6-Qs@1bkjzd1.ch3.sourceforge.com>

Bugs item #2608188, was opened at 2009-02-17 06:02
Message generated for change (Comment added) made by norm_brandinger
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=2608188&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: 8
Private: No
Submitted By: Om Bikram Thapa (omthapa)
Assigned to: Bogdan-Andrei Iancu (bogdan_iancu)
Summary: OpenSIPS latest trunk libmysqlclient segfault 

Initial Comment:
OpenSIPS latest trunk on Debian Lenny/AMD64 dies with libmysqlclient segfault after a MySQL restart. The event that triggers this crash is registration related database query immediately after a MySQL restart. Once OpenSIPS is restarted after a crash, everything runs fine until next MySQL restart.

The log shows:

"opensips[16769]: segfault at 4c8 ip 7f36728bf283 sp 7fff7ba11a90 error 4 in libmysqlclient.so.15.0.0[7f3672862000+1bf000]"
 
and gdb bt gives following results:

---------------
Program terminated with signal 11, Segmentation fault.
[New process 16769]
#0  0x00007f36728bf283 in mysql_stmt_result_metadata ()
   from /usr/lib/libmysqlclient.so.15
(gdb) bt
#0  0x00007f36728bf283 in mysql_stmt_result_metadata ()
   from /usr/lib/libmysqlclient.so.15
#1  0x00007f3672c707b7 in db_mysql_do_prepared_query (conn=0x78b278, 
    query=<value optimized out>, v=0x7fff7ba11d20, n=1, uv=0x0, un=0)
    at dbase.c:363
#2  0x00007f3672c72e1f in db_mysql_query (_h=0x78b278, 
    _k=<value optimized out>, _op=<value optimized out>, _v=0x7fff7ba11d20, 
    _c=<value optimized out>, _n=1, _nc=2, _o=0x0, _r=0x7fff7ba11dc0)
    at dbase.c:591
#3  0x00007f366f3f0398 in authorize (_m=0x78fe98, 
    _realm=<value optimized out>, _table=<value optimized out>, 
    _hftype=<value optimized out>) at authorize.c:107
#4  0x000000000040f869 in do_action (a=0x780a48, msg=0x78fe98) at action.c:961
#5  0x000000000040e7e5 in run_action_list (a=<value optimized out>, 
    msg=0x78fe98) at action.c:139
#6  0x000000000046f194 in eval_elem (e=0x780b18, msg=0x78fe98, val=0x0)
    at route.c:1189
#7  0x00000000004708ed in eval_expr (e=0x120b1e0, msg=0x78fe98, val=0x0)
    at route.c:1486
#8  0x000000000047089c in eval_expr (e=0x780b60, msg=0x78fe98, val=0x0)
    at route.c:1502
#9  0x00000000004708c5 in eval_expr (e=0x780ba8, msg=0x78fe98, val=0x0)
    at route.c:1507
---Type <return> to continue, or q <return> to quit---
#10 0x000000000040f91c in do_action (a=0x780f40, msg=0x78fe98) at action.c:688
#11 0x000000000040e7e5 in run_action_list (a=<value optimized out>, 
    msg=0x78fe98) at action.c:139
#12 0x00000000004114d3 in do_action (a=0x781eb0, msg=0x78fe98) at action.c:705
#13 0x000000000040e7e5 in run_action_list (a=<value optimized out>, 
    msg=0x78fe98) at action.c:139
#14 0x0000000000410e07 in do_action (a=0x77ee88, msg=0x78fe98) at action.c:119
#15 0x000000000040e7e5 in run_action_list (a=<value optimized out>, 
    msg=0x78fe98) at action.c:139
#16 0x00000000004114d3 in do_action (a=0x77f028, msg=0x78fe98) at action.c:705
#17 0x000000000040e7e5 in run_action_list (a=<value optimized out>, 
    msg=0x78fe98) at action.c:139
#18 0x00000000004125fe in run_top_route (a=0x777e78, msg=0x78fe98)
    at action.c:119
#19 0x000000000045e898 in receive_msg (
    buf=0x749180 "REGISTER sip:x.x.x.x SIP/2.0\r\nCSeq: 2 REGISTER\r\nVia: SIP/2.0/UDP x.x.x.x:5061;branch=z9hG4bK60f1b2dd-57fa-dd11-9401-0015c5404858;rport\r\nUser-Agent: Ekiga/2.0.12\r\nAuthorization: Dige"..., 
    len=749, rcv_info=0x7fff7ba13530) at receive.c:165
#20 0x000000000049d3a6 in udp_rcv_loop () at udp_server.c:449
#21 0x00000000004291fb in main (argc=<value optimized out>, 
    argv=0x7fff7ba13718) at main.c:778
----------------


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

Comment By: Norm Brandinger (norm_brandinger)
Date: 2009-02-20 20:37

Message:
Although this isn't a segfault, it's likely that fixing one MySQL problem
will fix others.  Below is the result of a fresh install on a newly
formatted system (debian 2.6.26-1-amd64) and the latest OpenSIPS trunk:

DBG:db_mysql:db_mysql_do_prepared_query: new query=|select
password,account_id from subscriber where username=?|
ERROR:db_mysql:get_new_stmt_ctx: failed while mysql_stmt_prepare()
ERROR:db_mysql:db_mysql_do_prepared_query: failed to create new context
ERROR:auth_db:get_ha1: failed to query database


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

Comment By: I?aki Baz (ibc_sf)
Date: 2009-02-20 10:46

Message:
My OpenSIPS rev-5351 crahses daily without restarting MySQL (Debian Etch 64
bits). Simple backtrace:

#0  0x00002b1cd7475a92 in mysql_stmt_result_metadata () from
/usr/lib/libmysqlclient.so.15
#1  0x00002b1cd730023c in db_mysql_free_result () from
/usr/lib/opensips/modules/db_mysql.so
#2  0x00002b1cd73013b6 in db_mysql_query () from
/usr/lib/opensips/modules/db_mysql.so
#3  0x00002b1cd859b8f8 in ?? () from /usr/lib/opensips/modules/auth_db.so
#4  0x000000000040f894 in do_action ()
#5  0x000000000040e0f3 in run_action_list ()
#6  0x000000000044c957 in eval_expr ()
#7  0x000000000044c3d0 in eval_expr ()
#8  0x000000000044c34f in eval_expr ()
#9  0x000000000040f939 in do_action ()
#10 0x000000000040e0f3 in run_action_list ()
#11 0x000000000041093a in do_action ()
#12 0x000000000040e0f3 in run_action_list ()
#13 0x000000000041176f in do_action ()
#14 0x000000000040e0f3 in run_action_list ()
#15 0x000000000040e480 in run_top_route ()
#16 0x0000000000441b4c in receive_msg ()
#17 0x0000000000464bfd in tcp_read_req ()
#18 0x000000000046691e in tcp_read_req ()
#19 0x0000000000468114 in tcp_receive_loop ()
#20 0x000000000045b83d in tcp_init_children ()
#21 0x000000000042368e in main ()


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

Comment By: Nobody/Anonymous (nobody)
Date: 2009-02-19 06:56

Message:
Hi Bogdan,

The issue remains with latest SVN also.

Here is the gdb trace now:

#0  0x00007f0119426283 in mysql_stmt_result_metadata () from
/usr/lib/libmysqlclient.so.15
(gdb) bt
#0  0x00007f0119426283 in mysql_stmt_result_metadata () from
/usr/lib/libmysqlclient.so.15
#1  0x00007f01197d8f82 in db_mysql_do_prepared_query (conn=0x78b278,
query=<value optimized out>, v=0x7fff22576880, n=<value optimized out>,
uv=0x0, un=0)
    at dbase.c:368
#2  0x00007f01197daccd in db_mysql_query (_h=0x78b278, _k=<value optimized
out>, _op=<value optimized out>, _v=0x7fff22576880, _c=<value optimized
out>, 
    _n=1, _nc=2, _o=0x0, _r=0x7fff22576920) at dbase.c:603
#3  0x00007f0115f56398 in authorize (_m=0x78fe98, _realm=<value optimized
out>, _table=<value optimized out>, _hftype=<value optimized out>)
    at authorize.c:107
#4  0x000000000040f869 in do_action (a=0x780a48, msg=0x78fe98) at
action.c:961
#5  0x000000000040e7e5 in run_action_list (a=<value optimized out>,
msg=0x78fe98) at action.c:139
#6  0x000000000046f194 in eval_elem (e=0x780b18, msg=0x78fe98, val=0x0) at
route.c:1189
#7  0x00000000004708ed in eval_expr (e=0x27648e0, msg=0x78fe98, val=0x0)
at route.c:1486
#8  0x000000000047089c in eval_expr (e=0x780b60, msg=0x78fe98, val=0x0) at
route.c:1502
#9  0x00000000004708c5 in eval_expr (e=0x780ba8, msg=0x78fe98, val=0x0) at
route.c:1507
#10 0x000000000040f91c in do_action (a=0x780f40, msg=0x78fe98) at
action.c:688
#11 0x000000000040e7e5 in run_action_list (a=<value optimized out>,
msg=0x78fe98) at action.c:139
#12 0x00000000004114d3 in do_action (a=0x781eb0, msg=0x78fe98) at
action.c:705
#13 0x000000000040e7e5 in run_action_list (a=<value optimized out>,
msg=0x78fe98) at action.c:139
#14 0x0000000000410e07 in do_action (a=0x77ee88, msg=0x78fe98) at
action.c:119
#15 0x000000000040e7e5 in run_action_list (a=<value optimized out>,
msg=0x78fe98) at action.c:139
#16 0x00000000004114d3 in do_action (a=0x77f028, msg=0x78fe98) at
action.c:705
#17 0x000000000040e7e5 in run_action_list (a=<value optimized out>,
msg=0x78fe98) at action.c:139
#18 0x00000000004125fe in run_top_route (a=0x777e78, msg=0x78fe98) at
action.c:119
#19 0x000000000045e898 in receive_msg (
    buf=0x749180 "REGISTER sip:x.x.x.x SIP/2.0\r\nCSeq: 58
REGISTER\r\nVia: SIP/2.0/UDP
x.x.x.x:5068;branch=z9hG4bK5ca4685b-befc-dd11-911f-0015c5404858;rport\r\nUser-Agent:
Ekiga/2.0.12\r\nAuthorization: Dig"..., len=750, rcv_info=0x7fff22578090)
at receive.c:165
#20 0x000000000049d3a6 in udp_rcv_loop () at udp_server.c:449
#21 0x00000000004291fb in main (argc=<value optimized out>,
argv=0x7fff22578278) at main.c:778


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

Comment By: Nobody/Anonymous (nobody)
Date: 2009-02-19 06:52

Message:
Hi Bogdan,

The issue remains with latest SVN also.

Here is the gdb trace now:

#0  0x00007f0119426283 in mysql_stmt_result_metadata () from
/usr/lib/libmysqlclient.so.15
(gdb) bt
#0  0x00007f0119426283 in mysql_stmt_result_metadata () from
/usr/lib/libmysqlclient.so.15
#1  0x00007f01197d8f82 in db_mysql_do_prepared_query (conn=0x78b278,
query=<value optimized out>, v=0x7fff22576880, n=<value optimized out>,
uv=0x0, un=0)
    at dbase.c:368
#2  0x00007f01197daccd in db_mysql_query (_h=0x78b278, _k=<value optimized
out>, _op=<value optimized out>, _v=0x7fff22576880, _c=<value optimized
out>, 
    _n=1, _nc=2, _o=0x0, _r=0x7fff22576920) at dbase.c:603
#3  0x00007f0115f56398 in authorize (_m=0x78fe98, _realm=<value optimized
out>, _table=<value optimized out>, _hftype=<value optimized out>)
    at authorize.c:107
#4  0x000000000040f869 in do_action (a=0x780a48, msg=0x78fe98) at
action.c:961
#5  0x000000000040e7e5 in run_action_list (a=<value optimized out>,
msg=0x78fe98) at action.c:139
#6  0x000000000046f194 in eval_elem (e=0x780b18, msg=0x78fe98, val=0x0) at
route.c:1189
#7  0x00000000004708ed in eval_expr (e=0x27648e0, msg=0x78fe98, val=0x0)
at route.c:1486
#8  0x000000000047089c in eval_expr (e=0x780b60, msg=0x78fe98, val=0x0) at
route.c:1502
#9  0x00000000004708c5 in eval_expr (e=0x780ba8, msg=0x78fe98, val=0x0) at
route.c:1507
#10 0x000000000040f91c in do_action (a=0x780f40, msg=0x78fe98) at
action.c:688
#11 0x000000000040e7e5 in run_action_list (a=<value optimized out>,
msg=0x78fe98) at action.c:139
#12 0x00000000004114d3 in do_action (a=0x781eb0, msg=0x78fe98) at
action.c:705
#13 0x000000000040e7e5 in run_action_list (a=<value optimized out>,
msg=0x78fe98) at action.c:139
#14 0x0000000000410e07 in do_action (a=0x77ee88, msg=0x78fe98) at
action.c:119
#15 0x000000000040e7e5 in run_action_list (a=<value optimized out>,
msg=0x78fe98) at action.c:139
#16 0x00000000004114d3 in do_action (a=0x77f028, msg=0x78fe98) at
action.c:705
#17 0x000000000040e7e5 in run_action_list (a=<value optimized out>,
msg=0x78fe98) at action.c:139
#18 0x00000000004125fe in run_top_route (a=0x777e78, msg=0x78fe98) at
action.c:119
#19 0x000000000045e898 in receive_msg (
    buf=0x749180 "REGISTER sip:x.x.x.x SIP/2.0\r\nCSeq: 58
REGISTER\r\nVia: SIP/2.0/UDP
x.x.x.x:5068;branch=z9hG4bK5ca4685b-befc-dd11-911f-0015c5404858;rport\r\nUser-Agent:
Ekiga/2.0.12\r\nAuthorization: Dig"..., len=750, rcv_info=0x7fff22578090)
at receive.c:165
#20 0x000000000049d3a6 in udp_rcv_loop () at udp_server.c:449
#21 0x00000000004291fb in main (argc=<value optimized out>,
argv=0x7fff22578278) at main.c:778


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

Comment By: Bogdan-Andrei Iancu (bogdan_iancu)
Date: 2009-02-18 21:02

Message:
Hi Om,

I hopefully fixed the problem - please update from SVN and give it another
try. Let me know if now works.

Thanks and regards,
Bogdan

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

Comment By: Om Bikram Thapa (omthapa)
Date: 2009-02-18 13:11

Message:
I modified domain in opensips domain table, immediately after that the
server crashed upon registration event with log  general protection
ip:7f249016986c sp:7fff992bf320 error:0 in
libmysqlclient.so.15.0.0[7f2490110000+1bf000]" and gdb backtrace now points
to different code:

----------
#0  0x00007f7a4c26f86c in mysql_stmt_fetch () from
/usr/lib/libmysqlclient.so.15
#1  0x00007f7a4c628a48 in db_mysql_convert_result (_h=0x78b278,
_r=0x78ba28) at res.c:161
#2  0x00007f7a4c626aaa in db_mysql_store_result (_h=0x78b278,
_r=0x7fff553c5770) at dbase.c:513
#3  0x00007f7a4c626e39 in db_mysql_query (_h=0x78b278, _k=<value optimized
out>, _op=<value optimized out>, _v=0x7fff553c56d0, _c=<value optimized
out>,
    _n=1, _nc=2, _o=0x0, _r=0x7fff553c5770) at dbase.c:593
#4  0x00007f7a48da4398 in authorize (_m=0x78fe98, _realm=<value optimized
out>, _table=<value optimized out>, _hftype=<value optimized out>)
    at authorize.c:107
#5  0x000000000040f869 in do_action (a=0x780a48, msg=0x78fe98) at
action.c:961
#6  0x000000000040e7e5 in run_action_list (a=<value optimized out>,
msg=0x78fe98) at action.c:139
#7  0x000000000046f194 in eval_elem (e=0x780b18, msg=0x78fe98, val=0x20)
at route.c:1189
#8  0x00000000004708ed in eval_expr (e=0xe543d0, msg=0x78fe98, val=0x0) at
route.c:1486
#9  0x000000000047089c in eval_expr (e=0x780b60, msg=0x78fe98, val=0x0) at
route.c:1502
#10 0x00000000004708c5 in eval_expr (e=0x780ba8, msg=0x78fe98, val=0x0) at
route.c:1507
#11 0x000000000040f91c in do_action (a=0x780f40, msg=0x78fe98) at
action.c:688
#12 0x000000000040e7e5 in run_action_list (a=<value optimized out>,
msg=0x78fe98) at action.c:139
#13 0x00000000004114d3 in do_action (a=0x781eb0, msg=0x78fe98) at
action.c:705
#14 0x000000000040e7e5 in run_action_list (a=<value optimized out>,
msg=0x78fe98) at action.c:139
#15 0x0000000000410e07 in do_action (a=0x77ee88, msg=0x78fe98) at
action.c:119
#16 0x000000000040e7e5 in run_action_list (a=<value optimized out>,
msg=0x78fe98) at action.c:139
#17 0x00000000004114d3 in do_action (a=0x77f028, msg=0x78fe98) at
action.c:705
#18 0x000000000040e7e5 in run_action_list (a=<value optimized out>,
msg=0x78fe98) at action.c:139
#19 0x00000000004125fe in run_top_route (a=0x777e78, msg=0x78fe98) at
action.c:119
#20 0x000000000045e898 in receive_msg (
    buf=0x749180 "REGISTER sip:x.x.x.x;transport=UDP SIP/2.0\r\nVia:
SIP/2.0/UDP
x.x.x.x:5060;branch=z9hG4bKgcjsr9edklicvlhif2tfvub;rport\r\nFrom:
<sip:300000 at x.x."..., len=693, rcv_info=0x7fff553c6ee0) at receive.c:165
#21 0x000000000049d3a6 in udp_rcv_loop () at udp_server.c:449
#22 0x00000000004291fb in main (argc=<value optimized out>,
argv=0x7fff553c70c8) at main.c:778
-----------------

I think this crash is also related to the same issue.

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

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


From noreply at sourceforge.net  Fri Feb 20 22:09:41 2009
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 20 Feb 2009 21:09:41 +0000
Subject: [OpenSIPS-Devel] [ opensips-Bugs-2608188 ] OpenSIPS latest trunk
	libmysqlclient segfault
Message-ID: <E1Laccv-0006iI-8p@cdv4jf1.ch3.sourceforge.com>

Bugs item #2608188, was opened at 2009-02-17 06:02
Message generated for change (Comment added) made by norm_brandinger
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=2608188&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: 8
Private: No
Submitted By: Om Bikram Thapa (omthapa)
Assigned to: Bogdan-Andrei Iancu (bogdan_iancu)
Summary: OpenSIPS latest trunk libmysqlclient segfault 

Initial Comment:
OpenSIPS latest trunk on Debian Lenny/AMD64 dies with libmysqlclient segfault after a MySQL restart. The event that triggers this crash is registration related database query immediately after a MySQL restart. Once OpenSIPS is restarted after a crash, everything runs fine until next MySQL restart.

The log shows:

"opensips[16769]: segfault at 4c8 ip 7f36728bf283 sp 7fff7ba11a90 error 4 in libmysqlclient.so.15.0.0[7f3672862000+1bf000]"
 
and gdb bt gives following results:

---------------
Program terminated with signal 11, Segmentation fault.
[New process 16769]
#0  0x00007f36728bf283 in mysql_stmt_result_metadata ()
   from /usr/lib/libmysqlclient.so.15
(gdb) bt
#0  0x00007f36728bf283 in mysql_stmt_result_metadata ()
   from /usr/lib/libmysqlclient.so.15
#1  0x00007f3672c707b7 in db_mysql_do_prepared_query (conn=0x78b278, 
    query=<value optimized out>, v=0x7fff7ba11d20, n=1, uv=0x0, un=0)
    at dbase.c:363
#2  0x00007f3672c72e1f in db_mysql_query (_h=0x78b278, 
    _k=<value optimized out>, _op=<value optimized out>, _v=0x7fff7ba11d20, 
    _c=<value optimized out>, _n=1, _nc=2, _o=0x0, _r=0x7fff7ba11dc0)
    at dbase.c:591
#3  0x00007f366f3f0398 in authorize (_m=0x78fe98, 
    _realm=<value optimized out>, _table=<value optimized out>, 
    _hftype=<value optimized out>) at authorize.c:107
#4  0x000000000040f869 in do_action (a=0x780a48, msg=0x78fe98) at action.c:961
#5  0x000000000040e7e5 in run_action_list (a=<value optimized out>, 
    msg=0x78fe98) at action.c:139
#6  0x000000000046f194 in eval_elem (e=0x780b18, msg=0x78fe98, val=0x0)
    at route.c:1189
#7  0x00000000004708ed in eval_expr (e=0x120b1e0, msg=0x78fe98, val=0x0)
    at route.c:1486
#8  0x000000000047089c in eval_expr (e=0x780b60, msg=0x78fe98, val=0x0)
    at route.c:1502
#9  0x00000000004708c5 in eval_expr (e=0x780ba8, msg=0x78fe98, val=0x0)
    at route.c:1507
---Type <return> to continue, or q <return> to quit---
#10 0x000000000040f91c in do_action (a=0x780f40, msg=0x78fe98) at action.c:688
#11 0x000000000040e7e5 in run_action_list (a=<value optimized out>, 
    msg=0x78fe98) at action.c:139
#12 0x00000000004114d3 in do_action (a=0x781eb0, msg=0x78fe98) at action.c:705
#13 0x000000000040e7e5 in run_action_list (a=<value optimized out>, 
    msg=0x78fe98) at action.c:139
#14 0x0000000000410e07 in do_action (a=0x77ee88, msg=0x78fe98) at action.c:119
#15 0x000000000040e7e5 in run_action_list (a=<value optimized out>, 
    msg=0x78fe98) at action.c:139
#16 0x00000000004114d3 in do_action (a=0x77f028, msg=0x78fe98) at action.c:705
#17 0x000000000040e7e5 in run_action_list (a=<value optimized out>, 
    msg=0x78fe98) at action.c:139
#18 0x00000000004125fe in run_top_route (a=0x777e78, msg=0x78fe98)
    at action.c:119
#19 0x000000000045e898 in receive_msg (
    buf=0x749180 "REGISTER sip:x.x.x.x SIP/2.0\r\nCSeq: 2 REGISTER\r\nVia: SIP/2.0/UDP x.x.x.x:5061;branch=z9hG4bK60f1b2dd-57fa-dd11-9401-0015c5404858;rport\r\nUser-Agent: Ekiga/2.0.12\r\nAuthorization: Dige"..., 
    len=749, rcv_info=0x7fff7ba13530) at receive.c:165
#20 0x000000000049d3a6 in udp_rcv_loop () at udp_server.c:449
#21 0x00000000004291fb in main (argc=<value optimized out>, 
    argv=0x7fff7ba13718) at main.c:778
----------------


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

Comment By: Norm Brandinger (norm_brandinger)
Date: 2009-02-20 21:09

Message:
Sorry, my problem was self-inflicted.

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

Comment By: Norm Brandinger (norm_brandinger)
Date: 2009-02-20 20:37

Message:
Although this isn't a segfault, it's likely that fixing one MySQL problem
will fix others.  Below is the result of a fresh install on a newly
formatted system (debian 2.6.26-1-amd64) and the latest OpenSIPS trunk:

DBG:db_mysql:db_mysql_do_prepared_query: new query=|select
password,account_id from subscriber where username=?|
ERROR:db_mysql:get_new_stmt_ctx: failed while mysql_stmt_prepare()
ERROR:db_mysql:db_mysql_do_prepared_query: failed to create new context
ERROR:auth_db:get_ha1: failed to query database


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

Comment By: I?aki Baz (ibc_sf)
Date: 2009-02-20 10:46

Message:
My OpenSIPS rev-5351 crahses daily without restarting MySQL (Debian Etch 64
bits). Simple backtrace:

#0  0x00002b1cd7475a92 in mysql_stmt_result_metadata () from
/usr/lib/libmysqlclient.so.15
#1  0x00002b1cd730023c in db_mysql_free_result () from
/usr/lib/opensips/modules/db_mysql.so
#2  0x00002b1cd73013b6 in db_mysql_query () from
/usr/lib/opensips/modules/db_mysql.so
#3  0x00002b1cd859b8f8 in ?? () from /usr/lib/opensips/modules/auth_db.so
#4  0x000000000040f894 in do_action ()
#5  0x000000000040e0f3 in run_action_list ()
#6  0x000000000044c957 in eval_expr ()
#7  0x000000000044c3d0 in eval_expr ()
#8  0x000000000044c34f in eval_expr ()
#9  0x000000000040f939 in do_action ()
#10 0x000000000040e0f3 in run_action_list ()
#11 0x000000000041093a in do_action ()
#12 0x000000000040e0f3 in run_action_list ()
#13 0x000000000041176f in do_action ()
#14 0x000000000040e0f3 in run_action_list ()
#15 0x000000000040e480 in run_top_route ()
#16 0x0000000000441b4c in receive_msg ()
#17 0x0000000000464bfd in tcp_read_req ()
#18 0x000000000046691e in tcp_read_req ()
#19 0x0000000000468114 in tcp_receive_loop ()
#20 0x000000000045b83d in tcp_init_children ()
#21 0x000000000042368e in main ()


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

Comment By: Nobody/Anonymous (nobody)
Date: 2009-02-19 06:56

Message:
Hi Bogdan,

The issue remains with latest SVN also.

Here is the gdb trace now:

#0  0x00007f0119426283 in mysql_stmt_result_metadata () from
/usr/lib/libmysqlclient.so.15
(gdb) bt
#0  0x00007f0119426283 in mysql_stmt_result_metadata () from
/usr/lib/libmysqlclient.so.15
#1  0x00007f01197d8f82 in db_mysql_do_prepared_query (conn=0x78b278,
query=<value optimized out>, v=0x7fff22576880, n=<value optimized out>,
uv=0x0, un=0)
    at dbase.c:368
#2  0x00007f01197daccd in db_mysql_query (_h=0x78b278, _k=<value optimized
out>, _op=<value optimized out>, _v=0x7fff22576880, _c=<value optimized
out>, 
    _n=1, _nc=2, _o=0x0, _r=0x7fff22576920) at dbase.c:603
#3  0x00007f0115f56398 in authorize (_m=0x78fe98, _realm=<value optimized
out>, _table=<value optimized out>, _hftype=<value optimized out>)
    at authorize.c:107
#4  0x000000000040f869 in do_action (a=0x780a48, msg=0x78fe98) at
action.c:961
#5  0x000000000040e7e5 in run_action_list (a=<value optimized out>,
msg=0x78fe98) at action.c:139
#6  0x000000000046f194 in eval_elem (e=0x780b18, msg=0x78fe98, val=0x0) at
route.c:1189
#7  0x00000000004708ed in eval_expr (e=0x27648e0, msg=0x78fe98, val=0x0)
at route.c:1486
#8  0x000000000047089c in eval_expr (e=0x780b60, msg=0x78fe98, val=0x0) at
route.c:1502
#9  0x00000000004708c5 in eval_expr (e=0x780ba8, msg=0x78fe98, val=0x0) at
route.c:1507
#10 0x000000000040f91c in do_action (a=0x780f40, msg=0x78fe98) at
action.c:688
#11 0x000000000040e7e5 in run_action_list (a=<value optimized out>,
msg=0x78fe98) at action.c:139
#12 0x00000000004114d3 in do_action (a=0x781eb0, msg=0x78fe98) at
action.c:705
#13 0x000000000040e7e5 in run_action_list (a=<value optimized out>,
msg=0x78fe98) at action.c:139
#14 0x0000000000410e07 in do_action (a=0x77ee88, msg=0x78fe98) at
action.c:119
#15 0x000000000040e7e5 in run_action_list (a=<value optimized out>,
msg=0x78fe98) at action.c:139
#16 0x00000000004114d3 in do_action (a=0x77f028, msg=0x78fe98) at
action.c:705
#17 0x000000000040e7e5 in run_action_list (a=<value optimized out>,
msg=0x78fe98) at action.c:139
#18 0x00000000004125fe in run_top_route (a=0x777e78, msg=0x78fe98) at
action.c:119
#19 0x000000000045e898 in receive_msg (
    buf=0x749180 "REGISTER sip:x.x.x.x SIP/2.0\r\nCSeq: 58
REGISTER\r\nVia: SIP/2.0/UDP
x.x.x.x:5068;branch=z9hG4bK5ca4685b-befc-dd11-911f-0015c5404858;rport\r\nUser-Agent:
Ekiga/2.0.12\r\nAuthorization: Dig"..., len=750, rcv_info=0x7fff22578090)
at receive.c:165
#20 0x000000000049d3a6 in udp_rcv_loop () at udp_server.c:449
#21 0x00000000004291fb in main (argc=<value optimized out>,
argv=0x7fff22578278) at main.c:778


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

Comment By: Nobody/Anonymous (nobody)
Date: 2009-02-19 06:52

Message:
Hi Bogdan,

The issue remains with latest SVN also.

Here is the gdb trace now:

#0  0x00007f0119426283 in mysql_stmt_result_metadata () from
/usr/lib/libmysqlclient.so.15
(gdb) bt
#0  0x00007f0119426283 in mysql_stmt_result_metadata () from
/usr/lib/libmysqlclient.so.15
#1  0x00007f01197d8f82 in db_mysql_do_prepared_query (conn=0x78b278,
query=<value optimized out>, v=0x7fff22576880, n=<value optimized out>,
uv=0x0, un=0)
    at dbase.c:368
#2  0x00007f01197daccd in db_mysql_query (_h=0x78b278, _k=<value optimized
out>, _op=<value optimized out>, _v=0x7fff22576880, _c=<value optimized
out>, 
    _n=1, _nc=2, _o=0x0, _r=0x7fff22576920) at dbase.c:603
#3  0x00007f0115f56398 in authorize (_m=0x78fe98, _realm=<value optimized
out>, _table=<value optimized out>, _hftype=<value optimized out>)
    at authorize.c:107
#4  0x000000000040f869 in do_action (a=0x780a48, msg=0x78fe98) at
action.c:961
#5  0x000000000040e7e5 in run_action_list (a=<value optimized out>,
msg=0x78fe98) at action.c:139
#6  0x000000000046f194 in eval_elem (e=0x780b18, msg=0x78fe98, val=0x0) at
route.c:1189
#7  0x00000000004708ed in eval_expr (e=0x27648e0, msg=0x78fe98, val=0x0)
at route.c:1486
#8  0x000000000047089c in eval_expr (e=0x780b60, msg=0x78fe98, val=0x0) at
route.c:1502
#9  0x00000000004708c5 in eval_expr (e=0x780ba8, msg=0x78fe98, val=0x0) at
route.c:1507
#10 0x000000000040f91c in do_action (a=0x780f40, msg=0x78fe98) at
action.c:688
#11 0x000000000040e7e5 in run_action_list (a=<value optimized out>,
msg=0x78fe98) at action.c:139
#12 0x00000000004114d3 in do_action (a=0x781eb0, msg=0x78fe98) at
action.c:705
#13 0x000000000040e7e5 in run_action_list (a=<value optimized out>,
msg=0x78fe98) at action.c:139
#14 0x0000000000410e07 in do_action (a=0x77ee88, msg=0x78fe98) at
action.c:119
#15 0x000000000040e7e5 in run_action_list (a=<value optimized out>,
msg=0x78fe98) at action.c:139
#16 0x00000000004114d3 in do_action (a=0x77f028, msg=0x78fe98) at
action.c:705
#17 0x000000000040e7e5 in run_action_list (a=<value optimized out>,
msg=0x78fe98) at action.c:139
#18 0x00000000004125fe in run_top_route (a=0x777e78, msg=0x78fe98) at
action.c:119
#19 0x000000000045e898 in receive_msg (
    buf=0x749180 "REGISTER sip:x.x.x.x SIP/2.0\r\nCSeq: 58
REGISTER\r\nVia: SIP/2.0/UDP
x.x.x.x:5068;branch=z9hG4bK5ca4685b-befc-dd11-911f-0015c5404858;rport\r\nUser-Agent:
Ekiga/2.0.12\r\nAuthorization: Dig"..., len=750, rcv_info=0x7fff22578090)
at receive.c:165
#20 0x000000000049d3a6 in udp_rcv_loop () at udp_server.c:449
#21 0x00000000004291fb in main (argc=<value optimized out>,
argv=0x7fff22578278) at main.c:778


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

Comment By: Bogdan-Andrei Iancu (bogdan_iancu)
Date: 2009-02-18 21:02

Message:
Hi Om,

I hopefully fixed the problem - please update from SVN and give it another
try. Let me know if now works.

Thanks and regards,
Bogdan

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

Comment By: Om Bikram Thapa (omthapa)
Date: 2009-02-18 13:11

Message:
I modified domain in opensips domain table, immediately after that the
server crashed upon registration event with log  general protection
ip:7f249016986c sp:7fff992bf320 error:0 in
libmysqlclient.so.15.0.0[7f2490110000+1bf000]" and gdb backtrace now points
to different code:

----------
#0  0x00007f7a4c26f86c in mysql_stmt_fetch () from
/usr/lib/libmysqlclient.so.15
#1  0x00007f7a4c628a48 in db_mysql_convert_result (_h=0x78b278,
_r=0x78ba28) at res.c:161
#2  0x00007f7a4c626aaa in db_mysql_store_result (_h=0x78b278,
_r=0x7fff553c5770) at dbase.c:513
#3  0x00007f7a4c626e39 in db_mysql_query (_h=0x78b278, _k=<value optimized
out>, _op=<value optimized out>, _v=0x7fff553c56d0, _c=<value optimized
out>,
    _n=1, _nc=2, _o=0x0, _r=0x7fff553c5770) at dbase.c:593
#4  0x00007f7a48da4398 in authorize (_m=0x78fe98, _realm=<value optimized
out>, _table=<value optimized out>, _hftype=<value optimized out>)
    at authorize.c:107
#5  0x000000000040f869 in do_action (a=0x780a48, msg=0x78fe98) at
action.c:961
#6  0x000000000040e7e5 in run_action_list (a=<value optimized out>,
msg=0x78fe98) at action.c:139
#7  0x000000000046f194 in eval_elem (e=0x780b18, msg=0x78fe98, val=0x20)
at route.c:1189
#8  0x00000000004708ed in eval_expr (e=0xe543d0, msg=0x78fe98, val=0x0) at
route.c:1486
#9  0x000000000047089c in eval_expr (e=0x780b60, msg=0x78fe98, val=0x0) at
route.c:1502
#10 0x00000000004708c5 in eval_expr (e=0x780ba8, msg=0x78fe98, val=0x0) at
route.c:1507
#11 0x000000000040f91c in do_action (a=0x780f40, msg=0x78fe98) at
action.c:688
#12 0x000000000040e7e5 in run_action_list (a=<value optimized out>,
msg=0x78fe98) at action.c:139
#13 0x00000000004114d3 in do_action (a=0x781eb0, msg=0x78fe98) at
action.c:705
#14 0x000000000040e7e5 in run_action_list (a=<value optimized out>,
msg=0x78fe98) at action.c:139
#15 0x0000000000410e07 in do_action (a=0x77ee88, msg=0x78fe98) at
action.c:119
#16 0x000000000040e7e5 in run_action_list (a=<value optimized out>,
msg=0x78fe98) at action.c:139
#17 0x00000000004114d3 in do_action (a=0x77f028, msg=0x78fe98) at
action.c:705
#18 0x000000000040e7e5 in run_action_list (a=<value optimized out>,
msg=0x78fe98) at action.c:139
#19 0x00000000004125fe in run_top_route (a=0x777e78, msg=0x78fe98) at
action.c:119
#20 0x000000000045e898 in receive_msg (
    buf=0x749180 "REGISTER sip:x.x.x.x;transport=UDP SIP/2.0\r\nVia:
SIP/2.0/UDP
x.x.x.x:5060;branch=z9hG4bKgcjsr9edklicvlhif2tfvub;rport\r\nFrom:
<sip:300000 at x.x."..., len=693, rcv_info=0x7fff553c6ee0) at receive.c:165
#21 0x000000000049d3a6 in udp_rcv_loop () at udp_server.c:449
#22 0x00000000004291fb in main (argc=<value optimized out>,
argv=0x7fff553c70c8) at main.c:778
-----------------

I think this crash is also related to the same issue.

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

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


From noreply at sourceforge.net  Fri Feb 20 22:15:36 2009
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 20 Feb 2009 21:15:36 +0000
Subject: [OpenSIPS-Devel] [ opensips-Patches-2621299 ] Enhance MySQL prepare
	statment diagnostics
Message-ID: <E1Lacie-0006Vs-U7@665xhf1.ch3.sourceforge.com>

Patches item #2621299, was opened at 2009-02-20 21:15
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086412&aid=2621299&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: Norm Brandinger (norm_brandinger)
Assigned to: Nobody/Anonymous (nobody)
Summary: Enhance MySQL prepare statment diagnostics

Initial Comment:
Enhance the diagnostics produced then the mysql_stmt_prepare() function fails.

For example, the unknown column that caused the failure is now provided.

ERROR:db_mysql:get_new_stmt_ctx: mysql_stmt_prepare() failed: Unknown column 'bad_column' in 'field list'

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

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


From noreply at sourceforge.net  Sun Feb 22 13:09:03 2009
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun, 22 Feb 2009 12:09:03 +0000
Subject: [OpenSIPS-Devel] [ opensips-Patches-2627561 ] auth_radius: allow
	sip-avps to be passed for rejected reques
Message-ID: <E1LbD8p-00046J-1u@cdv4jf1.ch3.sourceforge.com>

Patches item #2627561, was opened at 2009-02-22 14:09
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086412&aid=2627561&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.4.x
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Alex Massover (cupotka2008)
Assigned to: Nobody/Anonymous (nobody)
Summary: auth_radius: allow sip-avps to be passed for rejected reques

Initial Comment:
Hi!

This simple patch for auth_radius module allows to pass additional credentials (sip-avps) also for rejected radius requests. For example it can be used for passing custom error codes.

Best Regards,
Alex Massover.

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

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


From noreply at sourceforge.net  Mon Feb 23 14:27:37 2009
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 23 Feb 2009 13:27:37 +0000
Subject: [OpenSIPS-Devel] [ opensips-Patches-2621299 ] Enhance MySQL prepare
	statment diagnostics
Message-ID: <E1LbaqP-000616-7N@g45xhf1.ch3.sourceforge.com>

Patches item #2621299, was opened at 2009-02-20 21:15
Message generated for change (Comment added) made by norm_brandinger
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086412&aid=2621299&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: Norm Brandinger (norm_brandinger)
Assigned to: Nobody/Anonymous (nobody)
Summary: Enhance MySQL prepare statment diagnostics

Initial Comment:
Enhance the diagnostics produced then the mysql_stmt_prepare() function fails.

For example, the unknown column that caused the failure is now provided.

ERROR:db_mysql:get_new_stmt_ctx: mysql_stmt_prepare() failed: Unknown column 'bad_column' in 'field list'

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

>Comment By: Norm Brandinger (norm_brandinger)
Date: 2009-02-23 13:27

Message:
Updated the patch to add the enhanced diagnostic output for both prepare
statements located in the dbase.c file.  The original patch only updated
the first prepare statement.
File Added: dbase.c.patch2

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

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


From anca at opensips.org  Mon Feb 23 14:51:53 2009
From: anca at opensips.org (Anca Vamanu)
Date: Mon, 23 Feb 2009 13:51:53 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[5353]
	trunk/modules/presence_xml/notify_body.c
Message-ID: <E1LbbDt-0006Ms-Pq@3kljzd1.ch3.sourceforge.com>

Revision: 5353
          http://opensips.svn.sourceforge.net/opensips/?rev=5353&view=rev
Author:   anca_vamanu
Date:     2009-02-23 13:51:53 +0000 (Mon, 23 Feb 2009)

Log Message:
-----------
- fix: removed considering 'transformations' node in pres-rules xcap document to be compulsory

Modified Paths:
--------------
    trunk/modules/presence_xml/notify_body.c


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


From anca at opensips.org  Mon Feb 23 14:55:41 2009
From: anca at opensips.org (Anca Vamanu)
Date: Mon, 23 Feb 2009 13:55:41 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[5354]
	branches/1.4/modules/presence_xml/notify_body.c
Message-ID: <E1LbbHZ-0006QY-Ul@3kljzd1.ch3.sourceforge.com>

Revision: 5354
          http://opensips.svn.sourceforge.net/opensips/?rev=5354&view=rev
Author:   anca_vamanu
Date:     2009-02-23 13:55:41 +0000 (Mon, 23 Feb 2009)

Log Message:
-----------
- fix:	- removed considering the 'tuple' element in application/pidf+xml documents compulsory
		- removed considering 'transformations' node in pres-rules xcap document to be compulsory
	( reported by Oren K. )

Modified Paths:
--------------
    branches/1.4/modules/presence_xml/notify_body.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 Feb 23 14:57:31 2009
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 23 Feb 2009 13:57:31 +0000
Subject: [OpenSIPS-Devel] [ opensips-Bugs-2538399 ] Bug in presence when
	using fallback2db
Message-ID: <E1LbbJL-0006fL-Pn@h45xhf1.ch3.sourceforge.com>

Bugs item #2538399, was opened at 2009-01-26 21:39
Message generated for change (Comment added) made by anca_vamanu
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=2538399&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: Oren K (oren_k)
Assigned to: Anca Vamanu (anca_vamanu)
Summary: Bug in presence when using fallback2db

Initial Comment:
Hi,

While using the presence module, I run this scenario:

a. user1 SUBSCRIBE's to presence of user2
(subscription is now pending)

b. user2 allows user1 in pres-rules
(refreshWatchers is called, subscription is now active. user1 receives a NOTIFY from presence server with user2's current tuple and Subscription-State: active)

c. user2 PUBLISH'es a new presence tuple
-- at this point presence server should NOTIFY user1 of the new presence but it doesn't (that's the bug).


My modparams:

modparam("presence|presence_xml", "db_url", "mysql://root at localhost/opensips")

modparam("presence", "server_address", "sip:presence.example.com:10500")

modparam("presence", "fallback2db", 1)
modparam("presence", "clean_period", 30)


What I see in the debug trace is that get_subs_dialog (from notify.c) can't find any dialogs in the database, and all those in the subs hash are flagged NO_UPDATEDB_FLAG. This is probably what's causing the problem. 
Strangely, in the above scenario if user1 un-SUBSCRIBEs and re-SUBSCRIBEs to user2's presence - it does receive notifications.

Regards,
Oren K.

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

>Comment By: Anca Vamanu (anca_vamanu)
Date: 2009-02-23 15:57

Message:
Hi Oren,

I have fixed the problem with 'transformations' node. Please update and
test again.

Thanks,
Anca

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

Comment By: Oren K (oren_k)
Date: 2009-02-20 20:53

Message:
also I was getting errors because I didn't have a transformations node. The
common-policy schema states that transformations isn't a must-have, and I
think opensips should treat no transformations node the same as if there
was an empty one.

<xs:element name="transformations" type="cp:extensibleType"
minOccurs="0"/>

However, adding a <transformations/> to my pres-rules had not effect on
this bug (still happens).

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

Comment By: Oren K (oren_k)
Date: 2009-02-20 20:22

Message:
Something else is wrong now. mi_refresh_watchers is getting a timeout. This
didn't happen before. I'm using:
OpenXCAP 1.0.6
opensips-mi-proxy 1.0.2

Right now nothing works, not even normal scenarios.

Feb 20 13:16:22 openims opensips-mi-proxy[2368]: [-] error: Error while
processing command refreshWatchers (sip:user2 at openims.summit-tech.ca
presence 0): O
penSIPS command did timeout
Feb 20 13:16:22 openims opensips-mi-proxy[2368]: [-] Exception rendering:
Feb 20 13:16:22 openims opensips-mi-proxy[2368]: [-] Traceback (most
recent call last):
Feb 20 13:16:22 openims opensips-mi-proxy[2368]: [-]       File
"/usr/lib/python2.5/site-packages/Twisted-8.2.0_r25964-py2.5-linux-i686.egg/twisted/interne
t/defer.py", line 312, in _startRunCallbacks
Feb 20 13:16:22 openims opensips-mi-proxy[2368]: [-]        
self._runCallbacks()
Feb 20 13:16:22 openims opensips-mi-proxy[2368]: [-]       File
"/usr/lib/python2.5/site-packages/Twisted-8.2.0_r25964-py2.5-linux-i686.egg/twisted/interne
t/defer.py", line 328, in _runCallbacks
Feb 20 13:16:22 openims opensips-mi-proxy[2368]: [-]         self.result =
callback(self.result, *args, **kw)
Feb 20 13:16:22 openims opensips-mi-proxy[2368]: [-]       File
"/usr/lib/python2.5/site-packages/Twisted-8.2.0_r25964-py2.5-linux-i686.egg/twisted/interne
t/defer.py", line 289, in _continue
Feb 20 13:16:22 openims opensips-mi-proxy[2368]: [-]        
self.unpause()
Feb 20 13:16:22 openims opensips-mi-proxy[2368]: [-]       File
"/usr/lib/python2.5/site-packages/Twisted-8.2.0_r25964-py2.5-linux-i686.egg/twisted/interne
t/defer.py", line 285, in unpause
Feb 20 13:16:22 openims opensips-mi-proxy[2368]: [-]        
self._runCallbacks()
Feb 20 13:16:22 openims opensips-mi-proxy[2368]: [-]     --- <exception
caught here> ---
Feb 20 13:16:22 openims opensips-mi-proxy[2368]: [-]       File
"/usr/lib/python2.5/site-packages/Twisted-8.2.0_r25964-py2.5-linux-i686.egg/twisted/interne
t/defer.py", line 328, in _runCallbacks
Feb 20 13:16:22 openims opensips-mi-proxy[2368]: [-]         self.result =
callback(self.result, *args, **kw)
Feb 20 13:16:22 openims opensips-mi-proxy[2368]: [-]       File
"/usr/lib/python2.5/site-packages/miproxy/proxy.py", line 89, in _cbRender
Feb 20 13:16:22 openims opensips-mi-proxy[2368]: [-]         code =
int(code)
Feb 20 13:16:22 openims opensips-mi-proxy[2368]: [-]    
exceptions.ValueError: invalid literal for int() with base 10: 'OpenSIPS'


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

Comment By: Anca Vamanu (anca_vamanu)
Date: 2009-02-20 14:59

Message:
Hi,

I have just made a fix. Please update, test again and reply.

Thanks,
Anca

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

Comment By: Anca Vamanu (anca_vamanu)
Date: 2009-02-20 14:25

Message:
Hi Oren,

I have looked into the log file that you posted and saw that there was and
error there. There is a problem with the body of the Publish message -
which causes stopping the processing. The problem is that the code in the
presence server expects a tuple element in the body - and the body of the
last Publish message does not contain one.
I have looked up in the RFC and saw that the tuple element is in fact not
compulsory - so there is a bug in the presence code - but not the one you
reported :). 
I will fix this soon.

Thanks and regards,
Anca

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

Comment By: Oren K (oren_k)
Date: 2009-02-20 01:42

Message:
Still no joy.. adding updated log and pcap for the version i compiled from
svn 1.5.0dev5-tls.

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

Comment By: Anca Vamanu (anca_vamanu)
Date: 2009-02-18 18:11

Message:
Hi, 

I have just now made some changes in presence module for fallback2db case.
Can you please update to the newest svn version for 1.5 and test again?

regards,
Anca

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

Comment By: Anca Vamanu (anca_vamanu)
Date: 2009-02-18 18:10

Message:
Hi, 

I have just now made some changes in presence module for fallback2db case.
Can you please update to the newest svn version for 1.5 and test again?

regards,
Anca

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

Comment By: Oren K (oren_k)
Date: 2009-02-07 02:23

Message:
Hi Anca,

I've attached a debug-log and wireshark pcap file to the post. The pcap
file also contains the XCAP PUTs to change the presence rules. The only
error in the log comes from presence_xml not being able to extract a tuple
node because our client uses <pdm:person> for the presence (Same bug
happened to us when we tried with <tuple> so that's not the issue). The
things that strike me odd in presence_bug.log are:

(after step b. user2 allows user1 in pres-rules)
line 634: DBG:presence:update_pw_dialogs: found 1 matching dialogs

the module finds the watcher dialog and updates it due to refreshWatchers.
user1 receives a NOTIFY with Subscription-State:active. Now step c. user2
PUBLISH'es a new presence tuple:

line 919: DBG:core:parse_msg:  method:  <PUBLISH>

everything looks okay BUT:

line 1087: DBG:presence:get_subs_db: The query for subscribtion for [uri]=
sip:user2 at openims.summit-tech.ca for [event]= presence returned no result
line 1110: DBG:presence:get_subs_dialog: s->db_flag== UPDATEDB_FLAG
line 1111: DBG:presence:get_subs_dialog: found 0 dialogs( 0 in database
and 0 in hash_table)
line 1112: DBG:presence:publ_notify: Could not find subs_dialog

..suddenly there are no subscribers?

Thanks.


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

Comment By: Anca Vamanu (anca_vamanu)
Date: 2009-02-06 20:14

Message:
Hi Oren,

I have just downloaded myself the release and tested and the scenario that
you described works. 
Do you notice any error in your log file?

regards,
Anca

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

Comment By: Oren K (oren_k)
Date: 2009-02-01 18:41

Message:
Sorry I forgot to login, that comment is from me :)

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

Comment By: Nobody/Anonymous (nobody)
Date: 2009-01-28 17:12

Message:
Thanks for the reply anca. Version is opensips-1.4.4-tls, compiled from the
sources with TLS="1". 

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

Comment By: Anca Vamanu (anca_vamanu)
Date: 2009-01-28 13:48

Message:
Hi Oren,

What OpenSIPS version are you using? Trunk or stable release?

regards,
Anca

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

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


From noreply at sourceforge.net  Mon Feb 23 16:20:16 2009
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 23 Feb 2009 15:20:16 +0000
Subject: [OpenSIPS-Devel] [ opensips-Bugs-2609529 ] Segmentation fault
	related to 'pua' module
Message-ID: <E1LbcbQ-0006ae-74@b55xhf1.ch3.sourceforge.com>

Bugs item #2609529, was opened at 2009-02-17 17:35
Message generated for change (Comment added) made by ibc_sf
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=2609529&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: I?aki Baz (ibc_sf)
Assigned to: Anca Vamanu (anca_vamanu)
Summary: Segmentation fault related to 'pua' module

Initial Comment:
OpenSIPS rev 5323.

This OpenSIPS acts as a proxy for presence messages which are routed to an OpenSIPS presence server running in a different port.


syslog:
---------------
/usr/sbin/opensips[20978]: DBG:core:parse_msg:  version: <SIP/2.
/usr/sbin/opensips[20978]: DBG:core:parse_msg:  status:  <489>
/usr/sbin/opensips[20978]: DBG:core:parse_msg:  reason:  <Bad Ev
/usr/sbin/opensips[20978]: DBG:core:parse_headers: flags=2
/usr/sbin/opensips[20978]: DBG:core:parse_via_param: found param
/usr/sbin/opensips[20978]: DBG:core:parse_via: end of header rea
/usr/sbin/opensips[20978]: DBG:core:parse_headers: via found, fl
/usr/sbin/opensips[20978]: DBG:core:parse_headers: this is the f
/usr/sbin/opensips[20978]: DBG:core:receive_msg: After parse_msg
/usr/sbin/opensips[20978]: DBG:core:forward_reply: found module 
/usr/sbin/opensips[20978]: DBG:core:parse_headers: flags=4
/usr/sbin/opensips[20978]: DBG:core:parse_via_param: found param
/usr/sbin/opensips[20978]: DBG:core:parse_via_param: found param
/usr/sbin/opensips[20978]: DBG:core:parse_via_param: found param
/usr/sbin/opensips[20978]: DBG:core:parse_via: end of header rea
/usr/sbin/opensips[20978]: DBG:core:parse_headers: via found, fl
/usr/sbin/opensips[20978]: DBG:core:parse_headers: parse_headers
/usr/sbin/opensips[20978]: DBG:core:forward_reply: found module 
/usr/sbin/opensips[20978]: DBG:tm:t_check: start=0xfffffffffffff
/usr/sbin/opensips[20978]: DBG:core:parse_headers: flags=22
/usr/sbin/opensips[20978]: DBG:core:parse_to_param: tag=82e3ea5b
/usr/sbin/opensips[20978]: DBG:core:parse_to: end of header reac
/usr/sbin/opensips[20978]: DBG:core:parse_to: display={}, ruri={
/usr/sbin/opensips[20978]: DBG:core:get_hdr_field: <To> [63]; ur
/usr/sbin/opensips[20978]: DBG:core:get_hdr_field: to body [<sip
/usr/sbin/opensips[20978]: DBG:core:get_hdr_field: cseq <CSeq>: 
/usr/sbin/opensips[20978]: DBG:tm:t_reply_matching: hash 65085 l
/usr/sbin/opensips[20978]: DBG:tm:t_reply_matching: REF_UNSAFE: 
/usr/sbin/opensips[20978]: DBG:tm:t_reply_matching: reply matche
/usr/sbin/opensips[20978]: DBG:tm:run_trans_callbacks: trans=0x2
/usr/sbin/opensips[20978]: DBG:tm:t_check: end=0x2b936cb4ff10
/usr/sbin/opensips[20978]: DBG:tm:reply_received: org. status ua
/usr/sbin/opensips[20978]:  ## onreply_route[ON_REPLY_DEFAULT]
/usr/sbin/opensips[20978]: DBG:core:tr_eval_string: i=11 j=8
/usr/sbin/opensips[20978]: DBG:core:parse_headers: flags=8000000
/usr/sbin/opensips[20978]: DBG:core:get_hdr_field: content_lengt
/usr/sbin/opensips[20978]: DBG:core:get_hdr_field: found end of 
/usr/sbin/opensips[20978]: DBG:core:pv_get_useragent: no User-Ag
/usr/sbin/opensips[20978]: 15:43:27 - Reply from 99.131.79.216:5
/usr/sbin/opensips[20978]: 489 (SUBSCRIBE): Bad Event
/usr/sbin/opensips[20978]: DBG:tm:t_should_relay_response: T_cod
/usr/sbin/opensips[20978]: DBG:tm:t_pick_branch: picked branch 0
/usr/sbin/opensips[20978]: DBG:tm:is_3263_failure: dns-failover 
/usr/sbin/opensips[20978]: DBG:tm:relay_reply: branch=0, save=0,
/usr/sbin/opensips[20978]: DBG:core:build_res_buf_from_sip_res: 
/usr/sbin/opensips[20978]: DBG:core:build_res_buf_from_sip_res: 
/usr/sbin/opensips[20978]: DBG:core:_shm_resize: resize(0) calle
/usr/sbin/opensips[20978]: DBG:tm:insert_timer_unsafe: [2]: 0x2b
/usr/sbin/opensips[20978]: DBG:tm:relay_reply: sent buf=0x6b7920
/usr/sbin/opensips[20978]: DBG:tm:cleanup_uac_timers: RETR/FR ti
/usr/sbin/opensips[20978]: DBG:tm:t_unref: UNREF_UNSAFE: after i
/usr/sbin/opensips[20978]: DBG:core:destroy_avp_list: destroying
/usr/sbin/opensips[20978]: DBG:core:receive_msg: cleaning up
/usr/sbin/opensips[20934]: DBG:core:tcp_send: buf= SUBSCRIBE sip
/usr/sbin/opensips[20934]: DBG:tm:set_timer: relative timeout is
/usr/sbin/opensips[20934]: DBG:tm:insert_timer_unsafe: [0]: 0x2b
/usr/sbin/opensips[20934]: DBG:tm:t_relay_to: new transaction fw
/usr/sbin/opensips[20934]: DBG:tm:t_unref: UNREF_UNSAFE: after i
/usr/sbin/opensips[20934]: DBG:core:destroy_avp_list: destroying
/usr/sbin/opensips[20934]: DBG:core:receive_msg: cleaning up
/usr/sbin/opensips[20994]: CRITICAL:core:receive_fd: EOF on 46
---------------



coredump:
---------------
Core was generated by `/usr/sbin/opensips -P /var/run/opensips/opensips.pid -m 128 -u opensips -g open'.
Program terminated with signal 11, Segmentation fault.
#0  0x00002b936a901d78 in publ_build_hdr () from /usr/lib/opensips/modules/pua.so
(gdb) bt
#0  0x00002b936a901d78 in publ_build_hdr () from /usr/lib/opensips/modules/pua.so
#1  0x00002b936a8fee4c in bind_pua () from /usr/lib/opensips/modules/pua.so
#2  0x000000000046960c in start_timer_processes ()
#3  0x0000000000423661 in main ()
---------------

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

>Comment By: I?aki Baz (ibc_sf)
Date: 2009-02-23 16:20

Message:
@anca: I copied a core to the sources as you suggested:

------------------------------
(gdb) bt full
#0  0x00002b86e53b8a92 in mysql_stmt_result_metadata () from
/usr/lib/libmysqlclient.so.15
No symbol table info available.
#1  0x00002b86e524323c in db_mysql_free_result () from
/usr/lib/opensips/modules/db_mysql.so
No symbol table info available.
#2  0x00002b86e52443b6 in db_mysql_query () from
/usr/lib/opensips/modules/db_mysql.so
No symbol table info available.
#3  0x00002b86e64de8f8 in ?? () from /usr/lib/opensips/modules/auth_db.so
No symbol table info available.
#4  0x000000000040f894 in do_action ()
No symbol table info available.
#5  0x000000000040e0f3 in run_action_list ()
No symbol table info available.
#6  0x000000000044c957 in eval_expr ()
No symbol table info available.
#7  0x000000000044c3d0 in eval_expr ()
No symbol table info available.
#8  0x000000000044c34f in eval_expr ()
No symbol table info available.
#9  0x000000000040f939 in do_action ()
No symbol table info available.
#10 0x000000000040e0f3 in run_action_list ()
No symbol table info available.
#11 0x000000000041093a in do_action ()
No symbol table info available.
#12 0x000000000040e0f3 in run_action_list ()
No symbol table info available.
#13 0x000000000041176f in do_action ()
No symbol table info available.
#14 0x000000000040e0f3 in run_action_list ()
No symbol table info available.
#15 0x000000000040e480 in run_top_route ()
No symbol table info available.
#16 0x0000000000441b4c in receive_msg ()
No symbol table info available.
#17 0x0000000000464bfd in tcp_read_req ()
No symbol table info available.
#18 0x000000000046691e in tcp_read_req ()
No symbol table info available.
#19 0x0000000000468114 in tcp_receive_loop ()
No symbol table info available.
#20 0x000000000045b83d in tcp_init_children ()
No symbol table info available.
#21 0x000000000042368e in main ()
No symbol table info available.
------------------------------

I see no more useful info here anyway. Are the line numbers appear or
should I run the "ulimit" command?

Thanks.

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

Comment By: I?aki Baz (ibc_sf)
Date: 2009-02-18 18:34

Message:
Ok, I'll do that.
BTW my OpenSIPS proxy has crashed now with this backtrace:

------------
#0  0x00002b6c934ffa92 in mysql_stmt_result_metadata () from
/usr/lib/libmysqlclient.so.15
#1  0x00002b6c9338a1de in db_mysql_free_result () from
/usr/lib/opensips/modules/db_mysql.so
#2  0x00002b6c9338b156 in db_mysql_query () from
/usr/lib/opensips/modules/db_mysql.so
#3  0x00002b6c946258f8 in ?? () from /usr/lib/opensips/modules/auth_db.so
#4  0x000000000040f894 in do_action ()
#5  0x000000000040e0f3 in run_action_list ()
#6  0x000000000044c957 in eval_expr ()
#7  0x000000000044c3d0 in eval_expr ()
#8  0x000000000040f939 in do_action ()
#9  0x000000000040e0f3 in run_action_list ()
#10 0x000000000041093a in do_action ()
#11 0x000000000040e0f3 in run_action_list ()
#12 0x000000000041176f in do_action ()
#13 0x000000000040e0f3 in run_action_list ()
#14 0x000000000041176f in do_action ()
#15 0x000000000040e0f3 in run_action_list ()
#16 0x000000000040e480 in run_top_route ()
#17 0x0000000000441b4c in receive_msg ()
#18 0x0000000000464bfd in tcp_read_req ()
#19 0x000000000046691e in tcp_read_req ()
#20 0x0000000000468114 in tcp_receive_loop ()
#21 0x000000000045b83d in tcp_init_children ()
#22 0x000000000042368e in main ()
------------

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

Comment By: Anca Vamanu (anca_vamanu)
Date: 2009-02-18 16:39

Message:
Hi Inaki,

Neither the gdb back trace nor the log offer much information. Can you try
to copy the core in the directory where you have the sources and run from
there: 'gdb opensips core'. If still there are no line numbers - run
'ulimit -c unlimited' delete the old core and run the opensips again with
the same usage case to get a new core.
Please print here the output of the gdb back trace with 'bt full'.

regards,
Anca

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

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


From noreply at sourceforge.net  Mon Feb 23 16:27:42 2009
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 23 Feb 2009 15:27:42 +0000
Subject: [OpenSIPS-Devel] [ opensips-Bugs-2609529 ] Segmentation fault
	related to 'pua' module
Message-ID: <E1Lbcic-0005z9-76@g45xhf1.ch3.sourceforge.com>

Bugs item #2609529, was opened at 2009-02-17 18:35
Message generated for change (Comment added) made by anca_vamanu
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=2609529&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: I?aki Baz (ibc_sf)
Assigned to: Anca Vamanu (anca_vamanu)
Summary: Segmentation fault related to 'pua' module

Initial Comment:
OpenSIPS rev 5323.

This OpenSIPS acts as a proxy for presence messages which are routed to an OpenSIPS presence server running in a different port.


syslog:
---------------
/usr/sbin/opensips[20978]: DBG:core:parse_msg:  version: <SIP/2.
/usr/sbin/opensips[20978]: DBG:core:parse_msg:  status:  <489>
/usr/sbin/opensips[20978]: DBG:core:parse_msg:  reason:  <Bad Ev
/usr/sbin/opensips[20978]: DBG:core:parse_headers: flags=2
/usr/sbin/opensips[20978]: DBG:core:parse_via_param: found param
/usr/sbin/opensips[20978]: DBG:core:parse_via: end of header rea
/usr/sbin/opensips[20978]: DBG:core:parse_headers: via found, fl
/usr/sbin/opensips[20978]: DBG:core:parse_headers: this is the f
/usr/sbin/opensips[20978]: DBG:core:receive_msg: After parse_msg
/usr/sbin/opensips[20978]: DBG:core:forward_reply: found module 
/usr/sbin/opensips[20978]: DBG:core:parse_headers: flags=4
/usr/sbin/opensips[20978]: DBG:core:parse_via_param: found param
/usr/sbin/opensips[20978]: DBG:core:parse_via_param: found param
/usr/sbin/opensips[20978]: DBG:core:parse_via_param: found param
/usr/sbin/opensips[20978]: DBG:core:parse_via: end of header rea
/usr/sbin/opensips[20978]: DBG:core:parse_headers: via found, fl
/usr/sbin/opensips[20978]: DBG:core:parse_headers: parse_headers
/usr/sbin/opensips[20978]: DBG:core:forward_reply: found module 
/usr/sbin/opensips[20978]: DBG:tm:t_check: start=0xfffffffffffff
/usr/sbin/opensips[20978]: DBG:core:parse_headers: flags=22
/usr/sbin/opensips[20978]: DBG:core:parse_to_param: tag=82e3ea5b
/usr/sbin/opensips[20978]: DBG:core:parse_to: end of header reac
/usr/sbin/opensips[20978]: DBG:core:parse_to: display={}, ruri={
/usr/sbin/opensips[20978]: DBG:core:get_hdr_field: <To> [63]; ur
/usr/sbin/opensips[20978]: DBG:core:get_hdr_field: to body [<sip
/usr/sbin/opensips[20978]: DBG:core:get_hdr_field: cseq <CSeq>: 
/usr/sbin/opensips[20978]: DBG:tm:t_reply_matching: hash 65085 l
/usr/sbin/opensips[20978]: DBG:tm:t_reply_matching: REF_UNSAFE: 
/usr/sbin/opensips[20978]: DBG:tm:t_reply_matching: reply matche
/usr/sbin/opensips[20978]: DBG:tm:run_trans_callbacks: trans=0x2
/usr/sbin/opensips[20978]: DBG:tm:t_check: end=0x2b936cb4ff10
/usr/sbin/opensips[20978]: DBG:tm:reply_received: org. status ua
/usr/sbin/opensips[20978]:  ## onreply_route[ON_REPLY_DEFAULT]
/usr/sbin/opensips[20978]: DBG:core:tr_eval_string: i=11 j=8
/usr/sbin/opensips[20978]: DBG:core:parse_headers: flags=8000000
/usr/sbin/opensips[20978]: DBG:core:get_hdr_field: content_lengt
/usr/sbin/opensips[20978]: DBG:core:get_hdr_field: found end of 
/usr/sbin/opensips[20978]: DBG:core:pv_get_useragent: no User-Ag
/usr/sbin/opensips[20978]: 15:43:27 - Reply from 99.131.79.216:5
/usr/sbin/opensips[20978]: 489 (SUBSCRIBE): Bad Event
/usr/sbin/opensips[20978]: DBG:tm:t_should_relay_response: T_cod
/usr/sbin/opensips[20978]: DBG:tm:t_pick_branch: picked branch 0
/usr/sbin/opensips[20978]: DBG:tm:is_3263_failure: dns-failover 
/usr/sbin/opensips[20978]: DBG:tm:relay_reply: branch=0, save=0,
/usr/sbin/opensips[20978]: DBG:core:build_res_buf_from_sip_res: 
/usr/sbin/opensips[20978]: DBG:core:build_res_buf_from_sip_res: 
/usr/sbin/opensips[20978]: DBG:core:_shm_resize: resize(0) calle
/usr/sbin/opensips[20978]: DBG:tm:insert_timer_unsafe: [2]: 0x2b
/usr/sbin/opensips[20978]: DBG:tm:relay_reply: sent buf=0x6b7920
/usr/sbin/opensips[20978]: DBG:tm:cleanup_uac_timers: RETR/FR ti
/usr/sbin/opensips[20978]: DBG:tm:t_unref: UNREF_UNSAFE: after i
/usr/sbin/opensips[20978]: DBG:core:destroy_avp_list: destroying
/usr/sbin/opensips[20978]: DBG:core:receive_msg: cleaning up
/usr/sbin/opensips[20934]: DBG:core:tcp_send: buf= SUBSCRIBE sip
/usr/sbin/opensips[20934]: DBG:tm:set_timer: relative timeout is
/usr/sbin/opensips[20934]: DBG:tm:insert_timer_unsafe: [0]: 0x2b
/usr/sbin/opensips[20934]: DBG:tm:t_relay_to: new transaction fw
/usr/sbin/opensips[20934]: DBG:tm:t_unref: UNREF_UNSAFE: after i
/usr/sbin/opensips[20934]: DBG:core:destroy_avp_list: destroying
/usr/sbin/opensips[20934]: DBG:core:receive_msg: cleaning up
/usr/sbin/opensips[20994]: CRITICAL:core:receive_fd: EOF on 46
---------------



coredump:
---------------
Core was generated by `/usr/sbin/opensips -P /var/run/opensips/opensips.pid -m 128 -u opensips -g open'.
Program terminated with signal 11, Segmentation fault.
#0  0x00002b936a901d78 in publ_build_hdr () from /usr/lib/opensips/modules/pua.so
(gdb) bt
#0  0x00002b936a901d78 in publ_build_hdr () from /usr/lib/opensips/modules/pua.so
#1  0x00002b936a8fee4c in bind_pua () from /usr/lib/opensips/modules/pua.so
#2  0x000000000046960c in start_timer_processes ()
#3  0x0000000000423661 in main ()
---------------

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

>Comment By: Anca Vamanu (anca_vamanu)
Date: 2009-02-23 17:27

Message:
Hi Inaki,

It seems to be related to mysql prepare statements. There are some other
bug reports with this. Let
s wait for this problem to be fixed and see if the crash occurs also
after.

regards,
Anca

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

Comment By: I?aki Baz (ibc_sf)
Date: 2009-02-23 17:20

Message:
@anca: I copied a core to the sources as you suggested:

------------------------------
(gdb) bt full
#0  0x00002b86e53b8a92 in mysql_stmt_result_metadata () from
/usr/lib/libmysqlclient.so.15
No symbol table info available.
#1  0x00002b86e524323c in db_mysql_free_result () from
/usr/lib/opensips/modules/db_mysql.so
No symbol table info available.
#2  0x00002b86e52443b6 in db_mysql_query () from
/usr/lib/opensips/modules/db_mysql.so
No symbol table info available.
#3  0x00002b86e64de8f8 in ?? () from /usr/lib/opensips/modules/auth_db.so
No symbol table info available.
#4  0x000000000040f894 in do_action ()
No symbol table info available.
#5  0x000000000040e0f3 in run_action_list ()
No symbol table info available.
#6  0x000000000044c957 in eval_expr ()
No symbol table info available.
#7  0x000000000044c3d0 in eval_expr ()
No symbol table info available.
#8  0x000000000044c34f in eval_expr ()
No symbol table info available.
#9  0x000000000040f939 in do_action ()
No symbol table info available.
#10 0x000000000040e0f3 in run_action_list ()
No symbol table info available.
#11 0x000000000041093a in do_action ()
No symbol table info available.
#12 0x000000000040e0f3 in run_action_list ()
No symbol table info available.
#13 0x000000000041176f in do_action ()
No symbol table info available.
#14 0x000000000040e0f3 in run_action_list ()
No symbol table info available.
#15 0x000000000040e480 in run_top_route ()
No symbol table info available.
#16 0x0000000000441b4c in receive_msg ()
No symbol table info available.
#17 0x0000000000464bfd in tcp_read_req ()
No symbol table info available.
#18 0x000000000046691e in tcp_read_req ()
No symbol table info available.
#19 0x0000000000468114 in tcp_receive_loop ()
No symbol table info available.
#20 0x000000000045b83d in tcp_init_children ()
No symbol table info available.
#21 0x000000000042368e in main ()
No symbol table info available.
------------------------------

I see no more useful info here anyway. Are the line numbers appear or
should I run the "ulimit" command?

Thanks.

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

Comment By: I?aki Baz (ibc_sf)
Date: 2009-02-18 19:34

Message:
Ok, I'll do that.
BTW my OpenSIPS proxy has crashed now with this backtrace:

------------
#0  0x00002b6c934ffa92 in mysql_stmt_result_metadata () from
/usr/lib/libmysqlclient.so.15
#1  0x00002b6c9338a1de in db_mysql_free_result () from
/usr/lib/opensips/modules/db_mysql.so
#2  0x00002b6c9338b156 in db_mysql_query () from
/usr/lib/opensips/modules/db_mysql.so
#3  0x00002b6c946258f8 in ?? () from /usr/lib/opensips/modules/auth_db.so
#4  0x000000000040f894 in do_action ()
#5  0x000000000040e0f3 in run_action_list ()
#6  0x000000000044c957 in eval_expr ()
#7  0x000000000044c3d0 in eval_expr ()
#8  0x000000000040f939 in do_action ()
#9  0x000000000040e0f3 in run_action_list ()
#10 0x000000000041093a in do_action ()
#11 0x000000000040e0f3 in run_action_list ()
#12 0x000000000041176f in do_action ()
#13 0x000000000040e0f3 in run_action_list ()
#14 0x000000000041176f in do_action ()
#15 0x000000000040e0f3 in run_action_list ()
#16 0x000000000040e480 in run_top_route ()
#17 0x0000000000441b4c in receive_msg ()
#18 0x0000000000464bfd in tcp_read_req ()
#19 0x000000000046691e in tcp_read_req ()
#20 0x0000000000468114 in tcp_receive_loop ()
#21 0x000000000045b83d in tcp_init_children ()
#22 0x000000000042368e in main ()
------------

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

Comment By: Anca Vamanu (anca_vamanu)
Date: 2009-02-18 17:39

Message:
Hi Inaki,

Neither the gdb back trace nor the log offer much information. Can you try
to copy the core in the directory where you have the sources and run from
there: 'gdb opensips core'. If still there are no line numbers - run
'ulimit -c unlimited' delete the old core and run the opensips again with
the same usage case to get a new core.
Please print here the output of the gdb back trace with 'bt full'.

regards,
Anca

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

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


From noreply at sourceforge.net  Mon Feb 23 18:38:55 2009
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 23 Feb 2009 17:38:55 +0000
Subject: [OpenSIPS-Devel] [ opensips-Bugs-2538399 ] Bug in presence when
	using fallback2db
Message-ID: <E1Lbelb-00032b-Bx@1bkjzd1.ch3.sourceforge.com>

Bugs item #2538399, was opened at 2009-01-26 14:39
Message generated for change (Comment added) made by oren_k
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=2538399&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: Oren K (oren_k)
Assigned to: Anca Vamanu (anca_vamanu)
Summary: Bug in presence when using fallback2db

Initial Comment:
Hi,

While using the presence module, I run this scenario:

a. user1 SUBSCRIBE's to presence of user2
(subscription is now pending)

b. user2 allows user1 in pres-rules
(refreshWatchers is called, subscription is now active. user1 receives a NOTIFY from presence server with user2's current tuple and Subscription-State: active)

c. user2 PUBLISH'es a new presence tuple
-- at this point presence server should NOTIFY user1 of the new presence but it doesn't (that's the bug).


My modparams:

modparam("presence|presence_xml", "db_url", "mysql://root at localhost/opensips")

modparam("presence", "server_address", "sip:presence.example.com:10500")

modparam("presence", "fallback2db", 1)
modparam("presence", "clean_period", 30)


What I see in the debug trace is that get_subs_dialog (from notify.c) can't find any dialogs in the database, and all those in the subs hash are flagged NO_UPDATEDB_FLAG. This is probably what's causing the problem. 
Strangely, in the above scenario if user1 un-SUBSCRIBEs and re-SUBSCRIBEs to user2's presence - it does receive notifications.

Regards,
Oren K.

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

>Comment By: Oren K (oren_k)
Date: 2009-02-23 12:38

Message:
Thanks for your help Anca. I updated my sources from SVN and recompiled but
unfortunately the bug is still not resolved. I am still getting a crash
from opensips-mi-proxy, its the same one as on my previous comment from
Date: 2009-02-20 13:22

exceptions.ValueError: invalid literal for int() with base 10: 'OpenSIPS'

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

Comment By: Anca Vamanu (anca_vamanu)
Date: 2009-02-23 08:57

Message:
Hi Oren,

I have fixed the problem with 'transformations' node. Please update and
test again.

Thanks,
Anca

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

Comment By: Oren K (oren_k)
Date: 2009-02-20 13:53

Message:
also I was getting errors because I didn't have a transformations node. The
common-policy schema states that transformations isn't a must-have, and I
think opensips should treat no transformations node the same as if there
was an empty one.

<xs:element name="transformations" type="cp:extensibleType"
minOccurs="0"/>

However, adding a <transformations/> to my pres-rules had not effect on
this bug (still happens).

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

Comment By: Oren K (oren_k)
Date: 2009-02-20 13:22

Message:
Something else is wrong now. mi_refresh_watchers is getting a timeout. This
didn't happen before. I'm using:
OpenXCAP 1.0.6
opensips-mi-proxy 1.0.2

Right now nothing works, not even normal scenarios.

Feb 20 13:16:22 openims opensips-mi-proxy[2368]: [-] error: Error while
processing command refreshWatchers (sip:user2 at openims.summit-tech.ca
presence 0): O
penSIPS command did timeout
Feb 20 13:16:22 openims opensips-mi-proxy[2368]: [-] Exception rendering:
Feb 20 13:16:22 openims opensips-mi-proxy[2368]: [-] Traceback (most
recent call last):
Feb 20 13:16:22 openims opensips-mi-proxy[2368]: [-]       File
"/usr/lib/python2.5/site-packages/Twisted-8.2.0_r25964-py2.5-linux-i686.egg/twisted/interne
t/defer.py", line 312, in _startRunCallbacks
Feb 20 13:16:22 openims opensips-mi-proxy[2368]: [-]        
self._runCallbacks()
Feb 20 13:16:22 openims opensips-mi-proxy[2368]: [-]       File
"/usr/lib/python2.5/site-packages/Twisted-8.2.0_r25964-py2.5-linux-i686.egg/twisted/interne
t/defer.py", line 328, in _runCallbacks
Feb 20 13:16:22 openims opensips-mi-proxy[2368]: [-]         self.result =
callback(self.result, *args, **kw)
Feb 20 13:16:22 openims opensips-mi-proxy[2368]: [-]       File
"/usr/lib/python2.5/site-packages/Twisted-8.2.0_r25964-py2.5-linux-i686.egg/twisted/interne
t/defer.py", line 289, in _continue
Feb 20 13:16:22 openims opensips-mi-proxy[2368]: [-]        
self.unpause()
Feb 20 13:16:22 openims opensips-mi-proxy[2368]: [-]       File
"/usr/lib/python2.5/site-packages/Twisted-8.2.0_r25964-py2.5-linux-i686.egg/twisted/interne
t/defer.py", line 285, in unpause
Feb 20 13:16:22 openims opensips-mi-proxy[2368]: [-]        
self._runCallbacks()
Feb 20 13:16:22 openims opensips-mi-proxy[2368]: [-]     --- <exception
caught here> ---
Feb 20 13:16:22 openims opensips-mi-proxy[2368]: [-]       File
"/usr/lib/python2.5/site-packages/Twisted-8.2.0_r25964-py2.5-linux-i686.egg/twisted/interne
t/defer.py", line 328, in _runCallbacks
Feb 20 13:16:22 openims opensips-mi-proxy[2368]: [-]         self.result =
callback(self.result, *args, **kw)
Feb 20 13:16:22 openims opensips-mi-proxy[2368]: [-]       File
"/usr/lib/python2.5/site-packages/miproxy/proxy.py", line 89, in _cbRender
Feb 20 13:16:22 openims opensips-mi-proxy[2368]: [-]         code =
int(code)
Feb 20 13:16:22 openims opensips-mi-proxy[2368]: [-]    
exceptions.ValueError: invalid literal for int() with base 10: 'OpenSIPS'


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

Comment By: Anca Vamanu (anca_vamanu)
Date: 2009-02-20 07:59

Message:
Hi,

I have just made a fix. Please update, test again and reply.

Thanks,
Anca

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

Comment By: Anca Vamanu (anca_vamanu)
Date: 2009-02-20 07:25

Message:
Hi Oren,

I have looked into the log file that you posted and saw that there was and
error there. There is a problem with the body of the Publish message -
which causes stopping the processing. The problem is that the code in the
presence server expects a tuple element in the body - and the body of the
last Publish message does not contain one.
I have looked up in the RFC and saw that the tuple element is in fact not
compulsory - so there is a bug in the presence code - but not the one you
reported :). 
I will fix this soon.

Thanks and regards,
Anca

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

Comment By: Oren K (oren_k)
Date: 2009-02-19 18:42

Message:
Still no joy.. adding updated log and pcap for the version i compiled from
svn 1.5.0dev5-tls.

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

Comment By: Anca Vamanu (anca_vamanu)
Date: 2009-02-18 11:11

Message:
Hi, 

I have just now made some changes in presence module for fallback2db case.
Can you please update to the newest svn version for 1.5 and test again?

regards,
Anca

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

Comment By: Anca Vamanu (anca_vamanu)
Date: 2009-02-18 11:10

Message:
Hi, 

I have just now made some changes in presence module for fallback2db case.
Can you please update to the newest svn version for 1.5 and test again?

regards,
Anca

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

Comment By: Oren K (oren_k)
Date: 2009-02-06 19:23

Message:
Hi Anca,

I've attached a debug-log and wireshark pcap file to the post. The pcap
file also contains the XCAP PUTs to change the presence rules. The only
error in the log comes from presence_xml not being able to extract a tuple
node because our client uses <pdm:person> for the presence (Same bug
happened to us when we tried with <tuple> so that's not the issue). The
things that strike me odd in presence_bug.log are:

(after step b. user2 allows user1 in pres-rules)
line 634: DBG:presence:update_pw_dialogs: found 1 matching dialogs

the module finds the watcher dialog and updates it due to refreshWatchers.
user1 receives a NOTIFY with Subscription-State:active. Now step c. user2
PUBLISH'es a new presence tuple:

line 919: DBG:core:parse_msg:  method:  <PUBLISH>

everything looks okay BUT:

line 1087: DBG:presence:get_subs_db: The query for subscribtion for [uri]=
sip:user2 at openims.summit-tech.ca for [event]= presence returned no result
line 1110: DBG:presence:get_subs_dialog: s->db_flag== UPDATEDB_FLAG
line 1111: DBG:presence:get_subs_dialog: found 0 dialogs( 0 in database
and 0 in hash_table)
line 1112: DBG:presence:publ_notify: Could not find subs_dialog

..suddenly there are no subscribers?

Thanks.


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

Comment By: Anca Vamanu (anca_vamanu)
Date: 2009-02-06 13:14

Message:
Hi Oren,

I have just downloaded myself the release and tested and the scenario that
you described works. 
Do you notice any error in your log file?

regards,
Anca

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

Comment By: Oren K (oren_k)
Date: 2009-02-01 11:41

Message:
Sorry I forgot to login, that comment is from me :)

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

Comment By: Nobody/Anonymous (nobody)
Date: 2009-01-28 10:12

Message:
Thanks for the reply anca. Version is opensips-1.4.4-tls, compiled from the
sources with TLS="1". 

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

Comment By: Anca Vamanu (anca_vamanu)
Date: 2009-01-28 06:48

Message:
Hi Oren,

What OpenSIPS version are you using? Trunk or stable release?

regards,
Anca

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

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


From noreply at sourceforge.net  Tue Feb 24 05:30:49 2009
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 24 Feb 2009 04:30:49 +0000
Subject: [OpenSIPS-Devel] [ opensips-Bugs-2523454 ] Error in handling rls
	NOTIFY
Message-ID: <E1LbowT-0002Pd-Q4@d45xhf1.ch3.sourceforge.com>

Bugs item #2523454, was opened at 2009-01-20 11:55
Message generated for change (Comment added) made by nobody
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=2523454&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: Nathan (rmnathan)
Assigned to: Anca Vamanu (anca_vamanu)
Summary: Error in handling rls NOTIFY

Initial Comment:
Hi
The following error message are printed while handling rls notify.
Jan 20 06:45:44 [7833] ERROR:rls:parse_subs_state: terminated state and no reason foundJan 20 06:45:44 [7833] ERROR:rls:rls_handle_notify: while parsing 'Subscription-State' header
Jan 20 06:45:44 [7833] ERROR:rls:parse_subs_state: terminated state and no reason foundJan 20 06:45:44 [7833] ERROR:rls:rls_handle_notify: while parsing 'Subscription-State' header
Jan 20 06:45:44 [7833] ERROR:rls:parse_subs_state: terminated state and no reason foundJan 20 06:45:44 [7833] ERROR:rls:rls_handle_notify: while parsing 'Subscription-State' header
Jan 20 06:45:52 [7833] ERROR:rls:parse_subs_state: terminated state and no reason foundJan 20 06:45:52 [7833] ERROR:rls:rls_handle_notify: while parsing 'Subscription-State' header
Jan 20 06:45:52 [7833] ERROR:rls:parse_subs_state: terminated state and no reason foundJan 20 06:45:52 [7833] ERROR:rls:rls_handle_notify: while parsing 'Subscription-State' header
Jan 20 06:46:13 [7834] ERROR:core:db_do_insert: invalid parameter value
Jan 20 06:46:13 [7834] ERROR:pua:db_update: while inserting in db table pua
Jan 20 06:46:43 [7834] ERROR:core:parse_uri: uri too short: <> (0)
Jan 20 06:46:43 [7834] ERROR:tm:uri2proxy: bad_uri:
Jan 20 06:46:43 [7834] ERROR:tm:uri2su: failed create a dst proxy
Jan 20 06:46:43 [7834] ERROR:tm:t_uac: no socket found
Jan 20 06:46:43 [7834] ERROR:pua:update_pua: in t_request function
Jan 20 06:46:43 [7834] ERROR:pua:hashT_clean: while updating record
Jan 20 06:47:05 [7833] ERROR:rls:parse_subs_state: terminated state and no reason foundJan 20 06:47:05 [7833] ERROR:rls:rls_handle_notify: while parsing 'Subscription-State' header

Regards,
rmnathan


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

Comment By: Nobody/Anonymous (nobody)
Date: 2009-02-24 04:30

Message:
Hi
This is also scscf only. it is multiple process running on 192.168.166.150
with different ports for each process (ie for each user).

Thanks
rmnathan

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

Comment By: Anca Vamanu (anca_vamanu)
Date: 2009-02-20 12:09

Message:
Hi,

Can you tell me also what's running at 192.168.166.150:50607? 

thanks,
Anca

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

Comment By: Nathan (rmnathan)
Date: 2009-02-20 10:28

Message:
Hi Anca,
You are correct . That is not presence or rls server. It is registrar
(scscf) running on 192.168.166.150:50606. 
Please let me know if you want any information.

Thanks lot
rmnathan

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

Comment By: Anca Vamanu (anca_vamanu)
Date: 2009-02-19 12:03

Message:
Hi Rmnathan,

I looked through your trace but something is confusing.
Can you please tell me what was running on 192.168.166.150 port 50606. I
see that the User-Agent header is OpenSIPS, but the behavior doesn't seem
like that of a presence or rls server.

regards,
Anca

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

Comment By: Nathan (rmnathan)
Date: 2009-02-02 09:14

Message:
Hi Anca.
Yes, am using opensips as presence server and rls server. Please find the
logs and pcap file for call flow attached.

Regards,
rmnathan


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

Comment By: Anca Vamanu (anca_vamanu)
Date: 2009-01-22 13:25

Message:
Hi rmnathan,

Thank you for this report also.
There is something wrong with that Notify that gives this error.
Can you please trace the trafic and catch a Notify that generates this
error and print it here?
This Notify is received from the presence server. Are you using also
OpenSIPS as the presence server? Can you please check is the source IP
address of the Notify message is that of the presence server?

regards,
Anca

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

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


From noreply at sourceforge.net  Tue Feb 24 05:31:50 2009
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 24 Feb 2009 04:31:50 +0000
Subject: [OpenSIPS-Devel] [ opensips-Bugs-2523454 ] Error in handling rls
	NOTIFY
Message-ID: <E1LboxS-00075S-3I@1bkjzd1.ch3.sourceforge.com>

Bugs item #2523454, was opened at 2009-01-20 17:25
Message generated for change (Comment added) made by rmnathan
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=2523454&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: Nathan (rmnathan)
Assigned to: Anca Vamanu (anca_vamanu)
Summary: Error in handling rls NOTIFY

Initial Comment:
Hi
The following error message are printed while handling rls notify.
Jan 20 06:45:44 [7833] ERROR:rls:parse_subs_state: terminated state and no reason foundJan 20 06:45:44 [7833] ERROR:rls:rls_handle_notify: while parsing 'Subscription-State' header
Jan 20 06:45:44 [7833] ERROR:rls:parse_subs_state: terminated state and no reason foundJan 20 06:45:44 [7833] ERROR:rls:rls_handle_notify: while parsing 'Subscription-State' header
Jan 20 06:45:44 [7833] ERROR:rls:parse_subs_state: terminated state and no reason foundJan 20 06:45:44 [7833] ERROR:rls:rls_handle_notify: while parsing 'Subscription-State' header
Jan 20 06:45:52 [7833] ERROR:rls:parse_subs_state: terminated state and no reason foundJan 20 06:45:52 [7833] ERROR:rls:rls_handle_notify: while parsing 'Subscription-State' header
Jan 20 06:45:52 [7833] ERROR:rls:parse_subs_state: terminated state and no reason foundJan 20 06:45:52 [7833] ERROR:rls:rls_handle_notify: while parsing 'Subscription-State' header
Jan 20 06:46:13 [7834] ERROR:core:db_do_insert: invalid parameter value
Jan 20 06:46:13 [7834] ERROR:pua:db_update: while inserting in db table pua
Jan 20 06:46:43 [7834] ERROR:core:parse_uri: uri too short: <> (0)
Jan 20 06:46:43 [7834] ERROR:tm:uri2proxy: bad_uri:
Jan 20 06:46:43 [7834] ERROR:tm:uri2su: failed create a dst proxy
Jan 20 06:46:43 [7834] ERROR:tm:t_uac: no socket found
Jan 20 06:46:43 [7834] ERROR:pua:update_pua: in t_request function
Jan 20 06:46:43 [7834] ERROR:pua:hashT_clean: while updating record
Jan 20 06:47:05 [7833] ERROR:rls:parse_subs_state: terminated state and no reason foundJan 20 06:47:05 [7833] ERROR:rls:rls_handle_notify: while parsing 'Subscription-State' header

Regards,
rmnathan


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

Comment By: Nathan (rmnathan)
Date: 2009-02-24 10:01

Message:
Hi
This is also scscf only. it is multiple process running on 192.168.166.150
with different ports for each process (ie for each user).

Thanks
rmnathan

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

Comment By: Nobody/Anonymous (nobody)
Date: 2009-02-24 10:00

Message:
Hi
This is also scscf only. it is multiple process running on 192.168.166.150
with different ports for each process (ie for each user).

Thanks
rmnathan

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

Comment By: Anca Vamanu (anca_vamanu)
Date: 2009-02-20 17:39

Message:
Hi,

Can you tell me also what's running at 192.168.166.150:50607? 

thanks,
Anca

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

Comment By: Nathan (rmnathan)
Date: 2009-02-20 15:58

Message:
Hi Anca,
You are correct . That is not presence or rls server. It is registrar
(scscf) running on 192.168.166.150:50606. 
Please let me know if you want any information.

Thanks lot
rmnathan

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

Comment By: Anca Vamanu (anca_vamanu)
Date: 2009-02-19 17:33

Message:
Hi Rmnathan,

I looked through your trace but something is confusing.
Can you please tell me what was running on 192.168.166.150 port 50606. I
see that the User-Agent header is OpenSIPS, but the behavior doesn't seem
like that of a presence or rls server.

regards,
Anca

----------------------------------------------------------------------

Comment By: Nathan (rmnathan)
Date: 2009-02-02 14:44

Message:
Hi Anca.
Yes, am using opensips as presence server and rls server. Please find the
logs and pcap file for call flow attached.

Regards,
rmnathan


----------------------------------------------------------------------

Comment By: Anca Vamanu (anca_vamanu)
Date: 2009-01-22 18:55

Message:
Hi rmnathan,

Thank you for this report also.
There is something wrong with that Notify that gives this error.
Can you please trace the trafic and catch a Notify that generates this
error and print it here?
This Notify is received from the presence server. Are you using also
OpenSIPS as the presence server? Can you please check is the source IP
address of the Notify message is that of the presence server?

regards,
Anca

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=2523454&group_id=232389


From noreply at sourceforge.net  Tue Feb 24 07:23:20 2009
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 24 Feb 2009 06:23:20 +0000
Subject: [OpenSIPS-Devel] [ opensips-Bugs-2591935 ] Error in sending NOTIFY
	for PUBLISH in RLS mode
Message-ID: <E1LbqhM-0007TA-40@565xhf1.ch3.sourceforge.com>

Bugs item #2591935, was opened at 2009-02-12 12:01
Message generated for change (Comment added) made by rmnathan
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=2591935&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: Nathan (rmnathan)
Assigned to: Anca Vamanu (anca_vamanu)
Summary: Error in sending NOTIFY for PUBLISH in RLS mode

Initial Comment:
Hi
When opensips got publish for the user(say E1_1) which has in two list subscriptions, it is sending notify to one user only.
For example:
UE2_1 list will have 2 entry uri like E1_1,E1_2
UE2_2 list will have 2 entry uri like E1_2,E1_1

S2_1 subscribe to UE2_1
S2_2 subscribe to UE2_2
If E1_1 send publish, opensips sends notify to S2_1 only. But it should send notify to S2_2 too.

Please find the attached pcap file for detailed call flow.

Regards,
rmnathan


----------------------------------------------------------------------

Comment By: Nathan (rmnathan)
Date: 2009-02-24 11:53

Message:
Hi Anca,
I tried with latest trunk 5354 build. while starting opensips i got
following error message
stinbng46:/usr/local/trunk# /usr/local/sbin/opensips
Listening on
             udp: 10.6.2.246 [10.6.2.246]:5060
Aliases:
             udp: stinbng46:5060

stinbng46:/usr/local/trunk# Feb 24 11:46:35 [2520]
ERROR:core:db_check_table_version: invalid version 0 for table
rls_presentity found, expected 1
Feb 24 11:46:35 [2520] ERROR:rls:mod_init: error during table version
check.
Feb 24 11:46:35 [2520] ERROR:core:init_mod: failed to initialize module
rls
Feb 24 11:46:35 [2520] ERROR:core:main: error while initializing modules
i have   rls_presentity table also in opensips database.
mysql> desc rls_presentity
    -> ;
+----------------+------------------+------+-----+---------+----------------+
| Field          | Type             | Null | Key | Default | Extra        
 |
+----------------+------------------+------+-----+---------+----------------+
| id             | int(10) unsigned | NO   | PRI | NULL    |
auto_increment |
| rlsubs_did     | char(255)        | NO   | MUL |         |              
 |
| resource_uri   | char(128)        | NO   |     |         |              
 |
| content_type   | char(64)         | NO   |     |         |              
 |
| presence_state | blob             | NO   |     |         |              
 |
| expires        | int(11)          | NO   |     |         |              
 |
| updated        | int(11)          | NO   | MUL |         |              
 |
| auth_state     | int(11)          | NO   |     |         |              
 |
| reason         | char(64)         | NO   |     |         |              
 |
+----------------+------------------+------+-----+---------+----------------+
9 rows in set (0.00 sec)

I have changed and tried table version in script also 
INSERT INTO version (table_name, table_version) values
('rls_presentity','1');
  CREATE TABLE rls_presentity (
      id INT(10) UNSIGNED AUTO_INCREMENT PRIMARY KEY NOT NULL,
      rlsubs_did CHAR(255) NOT NULL,
      resource_uri CHAR(128) NOT NULL,
      content_type CHAR(64) NOT NULL,
      presence_state BLOB NOT NULL,
      expires INT(11) NOT NULL,
      updated INT(11) NOT NULL,
      auth_state INT(11) NOT NULL,
      reason CHAR(64) NOT NULL,
      CONSTRAINT rls_presentity_idx UNIQUE (rlsubs_did, resource_uri)
  ) ENGINE=MyISAM;
Again i got the same error.

Regards
rmnathan

----------------------------------------------------------------------

Comment By: Anca Vamanu (anca_vamanu)
Date: 2009-02-18 20:47

Message:
Hi Rmnathan,

Thank you for this report.
Indeed, you were right- not all update Notifies were sent due to a bug in
the code. I have fixed it. Please update to the new svn version and test it
yourself. I will wait for your feedback before closing this bug report.

regards,
Anca



----------------------------------------------------------------------

Comment By: Anca Vamanu (anca_vamanu)
Date: 2009-02-18 20:47

Message:
Hi Rmnathan,

Thank you for this report.
Indeed, you were right- not all update Notifies were sent due to a bug in
the code. I have fixed it. Please update to the new svn version and test it
yourself. I will wait for your feedback before closing this bug report.

regards,
Anca



----------------------------------------------------------------------

Comment By: Anca Vamanu (anca_vamanu)
Date: 2009-02-18 20:46

Message:
Hi Rmnathan,

Thank you for this report.
Indeed, you were right- not all update Notifies were sent due to a bug in
the code. I have fixed it. Please update to the new svn version and test it
yourself. I will wait for your feedback before closing this bug report.

regards,
Anca



----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=2591935&group_id=232389


From noreply at sourceforge.net  Tue Feb 24 10:41:26 2009
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 24 Feb 2009 09:41:26 +0000
Subject: [OpenSIPS-Devel] [ opensips-Bugs-2538399 ] Bug in presence when
	using fallback2db
Message-ID: <E1Lbtn4-000461-HA@155xhf1.ch3.sourceforge.com>

Bugs item #2538399, was opened at 2009-01-26 21:39
Message generated for change (Comment added) made by anca_vamanu
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=2538399&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: Oren K (oren_k)
Assigned to: Anca Vamanu (anca_vamanu)
Summary: Bug in presence when using fallback2db

Initial Comment:
Hi,

While using the presence module, I run this scenario:

a. user1 SUBSCRIBE's to presence of user2
(subscription is now pending)

b. user2 allows user1 in pres-rules
(refreshWatchers is called, subscription is now active. user1 receives a NOTIFY from presence server with user2's current tuple and Subscription-State: active)

c. user2 PUBLISH'es a new presence tuple
-- at this point presence server should NOTIFY user1 of the new presence but it doesn't (that's the bug).


My modparams:

modparam("presence|presence_xml", "db_url", "mysql://root at localhost/opensips")

modparam("presence", "server_address", "sip:presence.example.com:10500")

modparam("presence", "fallback2db", 1)
modparam("presence", "clean_period", 30)


What I see in the debug trace is that get_subs_dialog (from notify.c) can't find any dialogs in the database, and all those in the subs hash are flagged NO_UPDATEDB_FLAG. This is probably what's causing the problem. 
Strangely, in the above scenario if user1 un-SUBSCRIBEs and re-SUBSCRIBEs to user2's presence - it does receive notifications.

Regards,
Oren K.

----------------------------------------------------------------------

>Comment By: Anca Vamanu (anca_vamanu)
Date: 2009-02-24 11:41

Message:
Hi, 

It does not help me if you say what error you get in opensips-mi-proxy. It
would have been better if you said what is the error in opensips :) .
Please look in the log, find the error and print it here.

regards, 
Anca

----------------------------------------------------------------------

Comment By: Oren K (oren_k)
Date: 2009-02-23 19:38

Message:
Thanks for your help Anca. I updated my sources from SVN and recompiled but
unfortunately the bug is still not resolved. I am still getting a crash
from opensips-mi-proxy, its the same one as on my previous comment from
Date: 2009-02-20 13:22

exceptions.ValueError: invalid literal for int() with base 10: 'OpenSIPS'

----------------------------------------------------------------------

Comment By: Anca Vamanu (anca_vamanu)
Date: 2009-02-23 15:57

Message:
Hi Oren,

I have fixed the problem with 'transformations' node. Please update and
test again.

Thanks,
Anca

----------------------------------------------------------------------

Comment By: Oren K (oren_k)
Date: 2009-02-20 20:53

Message:
also I was getting errors because I didn't have a transformations node. The
common-policy schema states that transformations isn't a must-have, and I
think opensips should treat no transformations node the same as if there
was an empty one.

<xs:element name="transformations" type="cp:extensibleType"
minOccurs="0"/>

However, adding a <transformations/> to my pres-rules had not effect on
this bug (still happens).

----------------------------------------------------------------------

Comment By: Oren K (oren_k)
Date: 2009-02-20 20:22

Message:
Something else is wrong now. mi_refresh_watchers is getting a timeout. This
didn't happen before. I'm using:
OpenXCAP 1.0.6
opensips-mi-proxy 1.0.2

Right now nothing works, not even normal scenarios.

Feb 20 13:16:22 openims opensips-mi-proxy[2368]: [-] error: Error while
processing command refreshWatchers (sip:user2 at openims.summit-tech.ca
presence 0): O
penSIPS command did timeout
Feb 20 13:16:22 openims opensips-mi-proxy[2368]: [-] Exception rendering:
Feb 20 13:16:22 openims opensips-mi-proxy[2368]: [-] Traceback (most
recent call last):
Feb 20 13:16:22 openims opensips-mi-proxy[2368]: [-]       File
"/usr/lib/python2.5/site-packages/Twisted-8.2.0_r25964-py2.5-linux-i686.egg/twisted/interne
t/defer.py", line 312, in _startRunCallbacks
Feb 20 13:16:22 openims opensips-mi-proxy[2368]: [-]        
self._runCallbacks()
Feb 20 13:16:22 openims opensips-mi-proxy[2368]: [-]       File
"/usr/lib/python2.5/site-packages/Twisted-8.2.0_r25964-py2.5-linux-i686.egg/twisted/interne
t/defer.py", line 328, in _runCallbacks
Feb 20 13:16:22 openims opensips-mi-proxy[2368]: [-]         self.result =
callback(self.result, *args, **kw)
Feb 20 13:16:22 openims opensips-mi-proxy[2368]: [-]       File
"/usr/lib/python2.5/site-packages/Twisted-8.2.0_r25964-py2.5-linux-i686.egg/twisted/interne
t/defer.py", line 289, in _continue
Feb 20 13:16:22 openims opensips-mi-proxy[2368]: [-]        
self.unpause()
Feb 20 13:16:22 openims opensips-mi-proxy[2368]: [-]       File
"/usr/lib/python2.5/site-packages/Twisted-8.2.0_r25964-py2.5-linux-i686.egg/twisted/interne
t/defer.py", line 285, in unpause
Feb 20 13:16:22 openims opensips-mi-proxy[2368]: [-]        
self._runCallbacks()
Feb 20 13:16:22 openims opensips-mi-proxy[2368]: [-]     --- <exception
caught here> ---
Feb 20 13:16:22 openims opensips-mi-proxy[2368]: [-]       File
"/usr/lib/python2.5/site-packages/Twisted-8.2.0_r25964-py2.5-linux-i686.egg/twisted/interne
t/defer.py", line 328, in _runCallbacks
Feb 20 13:16:22 openims opensips-mi-proxy[2368]: [-]         self.result =
callback(self.result, *args, **kw)
Feb 20 13:16:22 openims opensips-mi-proxy[2368]: [-]       File
"/usr/lib/python2.5/site-packages/miproxy/proxy.py", line 89, in _cbRender
Feb 20 13:16:22 openims opensips-mi-proxy[2368]: [-]         code =
int(code)
Feb 20 13:16:22 openims opensips-mi-proxy[2368]: [-]    
exceptions.ValueError: invalid literal for int() with base 10: 'OpenSIPS'


----------------------------------------------------------------------

Comment By: Anca Vamanu (anca_vamanu)
Date: 2009-02-20 14:59

Message:
Hi,

I have just made a fix. Please update, test again and reply.

Thanks,
Anca

----------------------------------------------------------------------

Comment By: Anca Vamanu (anca_vamanu)
Date: 2009-02-20 14:25

Message:
Hi Oren,

I have looked into the log file that you posted and saw that there was and
error there. There is a problem with the body of the Publish message -
which causes stopping the processing. The problem is that the code in the
presence server expects a tuple element in the body - and the body of the
last Publish message does not contain one.
I have looked up in the RFC and saw that the tuple element is in fact not
compulsory - so there is a bug in the presence code - but not the one you
reported :). 
I will fix this soon.

Thanks and regards,
Anca

----------------------------------------------------------------------

Comment By: Oren K (oren_k)
Date: 2009-02-20 01:42

Message:
Still no joy.. adding updated log and pcap for the version i compiled from
svn 1.5.0dev5-tls.

----------------------------------------------------------------------

Comment By: Anca Vamanu (anca_vamanu)
Date: 2009-02-18 18:11

Message:
Hi, 

I have just now made some changes in presence module for fallback2db case.
Can you please update to the newest svn version for 1.5 and test again?

regards,
Anca

----------------------------------------------------------------------

Comment By: Anca Vamanu (anca_vamanu)
Date: 2009-02-18 18:10

Message:
Hi, 

I have just now made some changes in presence module for fallback2db case.
Can you please update to the newest svn version for 1.5 and test again?

regards,
Anca

----------------------------------------------------------------------

Comment By: Oren K (oren_k)
Date: 2009-02-07 02:23

Message:
Hi Anca,

I've attached a debug-log and wireshark pcap file to the post. The pcap
file also contains the XCAP PUTs to change the presence rules. The only
error in the log comes from presence_xml not being able to extract a tuple
node because our client uses <pdm:person> for the presence (Same bug
happened to us when we tried with <tuple> so that's not the issue). The
things that strike me odd in presence_bug.log are:

(after step b. user2 allows user1 in pres-rules)
line 634: DBG:presence:update_pw_dialogs: found 1 matching dialogs

the module finds the watcher dialog and updates it due to refreshWatchers.
user1 receives a NOTIFY with Subscription-State:active. Now step c. user2
PUBLISH'es a new presence tuple:

line 919: DBG:core:parse_msg:  method:  <PUBLISH>

everything looks okay BUT:

line 1087: DBG:presence:get_subs_db: The query for subscribtion for [uri]=
sip:user2 at openims.summit-tech.ca for [event]= presence returned no result
line 1110: DBG:presence:get_subs_dialog: s->db_flag== UPDATEDB_FLAG
line 1111: DBG:presence:get_subs_dialog: found 0 dialogs( 0 in database
and 0 in hash_table)
line 1112: DBG:presence:publ_notify: Could not find subs_dialog

..suddenly there are no subscribers?

Thanks.


----------------------------------------------------------------------

Comment By: Anca Vamanu (anca_vamanu)
Date: 2009-02-06 20:14

Message:
Hi Oren,

I have just downloaded myself the release and tested and the scenario that
you described works. 
Do you notice any error in your log file?

regards,
Anca

----------------------------------------------------------------------

Comment By: Oren K (oren_k)
Date: 2009-02-01 18:41

Message:
Sorry I forgot to login, that comment is from me :)

----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2009-01-28 17:12

Message:
Thanks for the reply anca. Version is opensips-1.4.4-tls, compiled from the
sources with TLS="1". 

----------------------------------------------------------------------

Comment By: Anca Vamanu (anca_vamanu)
Date: 2009-01-28 13:48

Message:
Hi Oren,

What OpenSIPS version are you using? Trunk or stable release?

regards,
Anca

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=2538399&group_id=232389


From noreply at sourceforge.net  Tue Feb 24 10:49:27 2009
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 24 Feb 2009 09:49:27 +0000
Subject: [OpenSIPS-Devel] [ opensips-Bugs-2591935 ] Error in sending NOTIFY
	for PUBLISH in RLS mode
Message-ID: <E1Lbtup-00054H-RG@565xhf1.ch3.sourceforge.com>

Bugs item #2591935, was opened at 2009-02-12 08:31
Message generated for change (Comment added) made by anca_vamanu
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=2591935&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: Nathan (rmnathan)
Assigned to: Anca Vamanu (anca_vamanu)
Summary: Error in sending NOTIFY for PUBLISH in RLS mode

Initial Comment:
Hi
When opensips got publish for the user(say E1_1) which has in two list subscriptions, it is sending notify to one user only.
For example:
UE2_1 list will have 2 entry uri like E1_1,E1_2
UE2_2 list will have 2 entry uri like E1_2,E1_1

S2_1 subscribe to UE2_1
S2_2 subscribe to UE2_2
If E1_1 send publish, opensips sends notify to S2_1 only. But it should send notify to S2_2 too.

Please find the attached pcap file for detailed call flow.

Regards,
rmnathan


----------------------------------------------------------------------

>Comment By: Anca Vamanu (anca_vamanu)
Date: 2009-02-24 11:49

Message:
Hi Rmnathan,

A change was made for many tables - changing varchar type to char and
since the structure was changed, the version of the tables was increased.
You need to get the new mysql script and recreate the table and also
update the version for rls_presentity table in 'version' table. However
since there are many tables for which the version was increased I would
recommend recreating the whole database.

regards,
Anca

----------------------------------------------------------------------

Comment By: Nathan (rmnathan)
Date: 2009-02-24 08:23

Message:
Hi Anca,
I tried with latest trunk 5354 build. while starting opensips i got
following error message
stinbng46:/usr/local/trunk# /usr/local/sbin/opensips
Listening on
             udp: 10.6.2.246 [10.6.2.246]:5060
Aliases:
             udp: stinbng46:5060

stinbng46:/usr/local/trunk# Feb 24 11:46:35 [2520]
ERROR:core:db_check_table_version: invalid version 0 for table
rls_presentity found, expected 1
Feb 24 11:46:35 [2520] ERROR:rls:mod_init: error during table version
check.
Feb 24 11:46:35 [2520] ERROR:core:init_mod: failed to initialize module
rls
Feb 24 11:46:35 [2520] ERROR:core:main: error while initializing modules
i have   rls_presentity table also in opensips database.
mysql> desc rls_presentity
    -> ;
+----------------+------------------+------+-----+---------+----------------+
| Field          | Type             | Null | Key | Default | Extra        
 |
+----------------+------------------+------+-----+---------+----------------+
| id             | int(10) unsigned | NO   | PRI | NULL    |
auto_increment |
| rlsubs_did     | char(255)        | NO   | MUL |         |              
 |
| resource_uri   | char(128)        | NO   |     |         |              
 |
| content_type   | char(64)         | NO   |     |         |              
 |
| presence_state | blob             | NO   |     |         |              
 |
| expires        | int(11)          | NO   |     |         |              
 |
| updated        | int(11)          | NO   | MUL |         |              
 |
| auth_state     | int(11)          | NO   |     |         |              
 |
| reason         | char(64)         | NO   |     |         |              
 |
+----------------+------------------+------+-----+---------+----------------+
9 rows in set (0.00 sec)

I have changed and tried table version in script also 
INSERT INTO version (table_name, table_version) values
('rls_presentity','1');
  CREATE TABLE rls_presentity (
      id INT(10) UNSIGNED AUTO_INCREMENT PRIMARY KEY NOT NULL,
      rlsubs_did CHAR(255) NOT NULL,
      resource_uri CHAR(128) NOT NULL,
      content_type CHAR(64) NOT NULL,
      presence_state BLOB NOT NULL,
      expires INT(11) NOT NULL,
      updated INT(11) NOT NULL,
      auth_state INT(11) NOT NULL,
      reason CHAR(64) NOT NULL,
      CONSTRAINT rls_presentity_idx UNIQUE (rlsubs_did, resource_uri)
  ) ENGINE=MyISAM;
Again i got the same error.

Regards
rmnathan

----------------------------------------------------------------------

Comment By: Anca Vamanu (anca_vamanu)
Date: 2009-02-18 17:17

Message:
Hi Rmnathan,

Thank you for this report.
Indeed, you were right- not all update Notifies were sent due to a bug in
the code. I have fixed it. Please update to the new svn version and test it
yourself. I will wait for your feedback before closing this bug report.

regards,
Anca



----------------------------------------------------------------------

Comment By: Anca Vamanu (anca_vamanu)
Date: 2009-02-18 17:17

Message:
Hi Rmnathan,

Thank you for this report.
Indeed, you were right- not all update Notifies were sent due to a bug in
the code. I have fixed it. Please update to the new svn version and test it
yourself. I will wait for your feedback before closing this bug report.

regards,
Anca



----------------------------------------------------------------------

Comment By: Anca Vamanu (anca_vamanu)
Date: 2009-02-18 17:16

Message:
Hi Rmnathan,

Thank you for this report.
Indeed, you were right- not all update Notifies were sent due to a bug in
the code. I have fixed it. Please update to the new svn version and test it
yourself. I will wait for your feedback before closing this bug report.

regards,
Anca



----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=2591935&group_id=232389


From noreply at sourceforge.net  Tue Feb 24 11:43:27 2009
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 24 Feb 2009 10:43:27 +0000
Subject: [OpenSIPS-Devel] [ opensips-Bugs-2591935 ] Error in sending NOTIFY
	for PUBLISH in RLS mode
Message-ID: <E1Lbul5-0001rV-SD@cdv4jf1.ch3.sourceforge.com>

Bugs item #2591935, was opened at 2009-02-12 12:01
Message generated for change (Comment added) made by rmnathan
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=2591935&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: Nathan (rmnathan)
Assigned to: Anca Vamanu (anca_vamanu)
Summary: Error in sending NOTIFY for PUBLISH in RLS mode

Initial Comment:
Hi
When opensips got publish for the user(say E1_1) which has in two list subscriptions, it is sending notify to one user only.
For example:
UE2_1 list will have 2 entry uri like E1_1,E1_2
UE2_2 list will have 2 entry uri like E1_2,E1_1

S2_1 subscribe to UE2_1
S2_2 subscribe to UE2_2
If E1_1 send publish, opensips sends notify to S2_1 only. But it should send notify to S2_2 too.

Please find the attached pcap file for detailed call flow.

Regards,
rmnathan


----------------------------------------------------------------------

Comment By: Nathan (rmnathan)
Date: 2009-02-24 16:13

Message:
Hi Anca,
After that i have tested. still the issue is not fixed. Now opensips is
generating notify for all the users(for first user) in the list but it
always sending to first user in the list only not for other users. 

Please see the attached pcap file.

Regards
rmnathan



----------------------------------------------------------------------

Comment By: Anca Vamanu (anca_vamanu)
Date: 2009-02-24 15:19

Message:
Hi Rmnathan,

A change was made for many tables - changing varchar type to char and
since the structure was changed, the version of the tables was increased.
You need to get the new mysql script and recreate the table and also
update the version for rls_presentity table in 'version' table. However
since there are many tables for which the version was increased I would
recommend recreating the whole database.

regards,
Anca

----------------------------------------------------------------------

Comment By: Nathan (rmnathan)
Date: 2009-02-24 11:53

Message:
Hi Anca,
I tried with latest trunk 5354 build. while starting opensips i got
following error message
stinbng46:/usr/local/trunk# /usr/local/sbin/opensips
Listening on
             udp: 10.6.2.246 [10.6.2.246]:5060
Aliases:
             udp: stinbng46:5060

stinbng46:/usr/local/trunk# Feb 24 11:46:35 [2520]
ERROR:core:db_check_table_version: invalid version 0 for table
rls_presentity found, expected 1
Feb 24 11:46:35 [2520] ERROR:rls:mod_init: error during table version
check.
Feb 24 11:46:35 [2520] ERROR:core:init_mod: failed to initialize module
rls
Feb 24 11:46:35 [2520] ERROR:core:main: error while initializing modules
i have   rls_presentity table also in opensips database.
mysql> desc rls_presentity
    -> ;
+----------------+------------------+------+-----+---------+----------------+
| Field          | Type             | Null | Key | Default | Extra        
 |
+----------------+------------------+------+-----+---------+----------------+
| id             | int(10) unsigned | NO   | PRI | NULL    |
auto_increment |
| rlsubs_did     | char(255)        | NO   | MUL |         |              
 |
| resource_uri   | char(128)        | NO   |     |         |              
 |
| content_type   | char(64)         | NO   |     |         |              
 |
| presence_state | blob             | NO   |     |         |              
 |
| expires        | int(11)          | NO   |     |         |              
 |
| updated        | int(11)          | NO   | MUL |         |              
 |
| auth_state     | int(11)          | NO   |     |         |              
 |
| reason         | char(64)         | NO   |     |         |              
 |
+----------------+------------------+------+-----+---------+----------------+
9 rows in set (0.00 sec)

I have changed and tried table version in script also 
INSERT INTO version (table_name, table_version) values
('rls_presentity','1');
  CREATE TABLE rls_presentity (
      id INT(10) UNSIGNED AUTO_INCREMENT PRIMARY KEY NOT NULL,
      rlsubs_did CHAR(255) NOT NULL,
      resource_uri CHAR(128) NOT NULL,
      content_type CHAR(64) NOT NULL,
      presence_state BLOB NOT NULL,
      expires INT(11) NOT NULL,
      updated INT(11) NOT NULL,
      auth_state INT(11) NOT NULL,
      reason CHAR(64) NOT NULL,
      CONSTRAINT rls_presentity_idx UNIQUE (rlsubs_did, resource_uri)
  ) ENGINE=MyISAM;
Again i got the same error.

Regards
rmnathan

----------------------------------------------------------------------

Comment By: Anca Vamanu (anca_vamanu)
Date: 2009-02-18 20:47

Message:
Hi Rmnathan,

Thank you for this report.
Indeed, you were right- not all update Notifies were sent due to a bug in
the code. I have fixed it. Please update to the new svn version and test it
yourself. I will wait for your feedback before closing this bug report.

regards,
Anca



----------------------------------------------------------------------

Comment By: Anca Vamanu (anca_vamanu)
Date: 2009-02-18 20:47

Message:
Hi Rmnathan,

Thank you for this report.
Indeed, you were right- not all update Notifies were sent due to a bug in
the code. I have fixed it. Please update to the new svn version and test it
yourself. I will wait for your feedback before closing this bug report.

regards,
Anca



----------------------------------------------------------------------

Comment By: Anca Vamanu (anca_vamanu)
Date: 2009-02-18 20:46

Message:
Hi Rmnathan,

Thank you for this report.
Indeed, you were right- not all update Notifies were sent due to a bug in
the code. I have fixed it. Please update to the new svn version and test it
yourself. I will wait for your feedback before closing this bug report.

regards,
Anca



----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=2591935&group_id=232389


From noreply at sourceforge.net  Tue Feb 24 12:29:26 2009
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 24 Feb 2009 11:29:26 +0000
Subject: [OpenSIPS-Devel] [ opensips-Bugs-2591935 ] Error in sending NOTIFY
	for PUBLISH in RLS mode
Message-ID: <E1LbvTa-0003It-Es@155xhf1.ch3.sourceforge.com>

Bugs item #2591935, was opened at 2009-02-12 08:31
Message generated for change (Comment added) made by anca_vamanu
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=2591935&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: Nathan (rmnathan)
Assigned to: Anca Vamanu (anca_vamanu)
Summary: Error in sending NOTIFY for PUBLISH in RLS mode

Initial Comment:
Hi
When opensips got publish for the user(say E1_1) which has in two list subscriptions, it is sending notify to one user only.
For example:
UE2_1 list will have 2 entry uri like E1_1,E1_2
UE2_2 list will have 2 entry uri like E1_2,E1_1

S2_1 subscribe to UE2_1
S2_2 subscribe to UE2_2
If E1_1 send publish, opensips sends notify to S2_1 only. But it should send notify to S2_2 too.

Please find the attached pcap file for detailed call flow.

Regards,
rmnathan


----------------------------------------------------------------------

>Comment By: Anca Vamanu (anca_vamanu)
Date: 2009-02-24 13:29

Message:
Hi Rmnathan,

If you really want to help me figure out what your problem is you have to
send simpler traces. Your trace is impossible to analize - you have 8 lists
with different names, but there are 4 pairs having the same content - so
there are actually only 4 unique lists. Then you use in 'From' header of
the SUBSCRIBE not the name of the list but anther uri - this is not
important in the SIP logic - but it makes impossible for me to follow the
messages since the Notifies that the RLS sends and receives will have the
same To and From headers.
Please if you want to help run a simpler case - only two Subscriptions to
lists that can have different names but the same content. 
One more question - do you use a presence server that receives the
Subscribe messages sent by the rls server and also Publish messages from
the clients? Or you send the Subscribes directly to the clients and they
reply with Notifies?
Please also include a description with the entities in the scenario and
the IP address and port they run at.

Thanks,
Anca


----------------------------------------------------------------------

Comment By: Nathan (rmnathan)
Date: 2009-02-24 12:43

Message:
Hi Anca,
After that i have tested. still the issue is not fixed. Now opensips is
generating notify for all the users(for first user) in the list but it
always sending to first user in the list only not for other users. 

Please see the attached pcap file.

Regards
rmnathan



----------------------------------------------------------------------

Comment By: Anca Vamanu (anca_vamanu)
Date: 2009-02-24 11:49

Message:
Hi Rmnathan,

A change was made for many tables - changing varchar type to char and
since the structure was changed, the version of the tables was increased.
You need to get the new mysql script and recreate the table and also
update the version for rls_presentity table in 'version' table. However
since there are many tables for which the version was increased I would
recommend recreating the whole database.

regards,
Anca

----------------------------------------------------------------------

Comment By: Nathan (rmnathan)
Date: 2009-02-24 08:23

Message:
Hi Anca,
I tried with latest trunk 5354 build. while starting opensips i got
following error message
stinbng46:/usr/local/trunk# /usr/local/sbin/opensips
Listening on
             udp: 10.6.2.246 [10.6.2.246]:5060
Aliases:
             udp: stinbng46:5060

stinbng46:/usr/local/trunk# Feb 24 11:46:35 [2520]
ERROR:core:db_check_table_version: invalid version 0 for table
rls_presentity found, expected 1
Feb 24 11:46:35 [2520] ERROR:rls:mod_init: error during table version
check.
Feb 24 11:46:35 [2520] ERROR:core:init_mod: failed to initialize module
rls
Feb 24 11:46:35 [2520] ERROR:core:main: error while initializing modules
i have   rls_presentity table also in opensips database.
mysql> desc rls_presentity
    -> ;
+----------------+------------------+------+-----+---------+----------------+
| Field          | Type             | Null | Key | Default | Extra        
 |
+----------------+------------------+------+-----+---------+----------------+
| id             | int(10) unsigned | NO   | PRI | NULL    |
auto_increment |
| rlsubs_did     | char(255)        | NO   | MUL |         |              
 |
| resource_uri   | char(128)        | NO   |     |         |              
 |
| content_type   | char(64)         | NO   |     |         |              
 |
| presence_state | blob             | NO   |     |         |              
 |
| expires        | int(11)          | NO   |     |         |              
 |
| updated        | int(11)          | NO   | MUL |         |              
 |
| auth_state     | int(11)          | NO   |     |         |              
 |
| reason         | char(64)         | NO   |     |         |              
 |
+----------------+------------------+------+-----+---------+----------------+
9 rows in set (0.00 sec)

I have changed and tried table version in script also 
INSERT INTO version (table_name, table_version) values
('rls_presentity','1');
  CREATE TABLE rls_presentity (
      id INT(10) UNSIGNED AUTO_INCREMENT PRIMARY KEY NOT NULL,
      rlsubs_did CHAR(255) NOT NULL,
      resource_uri CHAR(128) NOT NULL,
      content_type CHAR(64) NOT NULL,
      presence_state BLOB NOT NULL,
      expires INT(11) NOT NULL,
      updated INT(11) NOT NULL,
      auth_state INT(11) NOT NULL,
      reason CHAR(64) NOT NULL,
      CONSTRAINT rls_presentity_idx UNIQUE (rlsubs_did, resource_uri)
  ) ENGINE=MyISAM;
Again i got the same error.

Regards
rmnathan

----------------------------------------------------------------------

Comment By: Anca Vamanu (anca_vamanu)
Date: 2009-02-18 17:17

Message:
Hi Rmnathan,

Thank you for this report.
Indeed, you were right- not all update Notifies were sent due to a bug in
the code. I have fixed it. Please update to the new svn version and test it
yourself. I will wait for your feedback before closing this bug report.

regards,
Anca



----------------------------------------------------------------------

Comment By: Anca Vamanu (anca_vamanu)
Date: 2009-02-18 17:17

Message:
Hi Rmnathan,

Thank you for this report.
Indeed, you were right- not all update Notifies were sent due to a bug in
the code. I have fixed it. Please update to the new svn version and test it
yourself. I will wait for your feedback before closing this bug report.

regards,
Anca



----------------------------------------------------------------------

Comment By: Anca Vamanu (anca_vamanu)
Date: 2009-02-18 17:16

Message:
Hi Rmnathan,

Thank you for this report.
Indeed, you were right- not all update Notifies were sent due to a bug in
the code. I have fixed it. Please update to the new svn version and test it
yourself. I will wait for your feedback before closing this bug report.

regards,
Anca



----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=2591935&group_id=232389


From noreply at sourceforge.net  Tue Feb 24 12:33:02 2009
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 24 Feb 2009 11:33:02 +0000
Subject: [OpenSIPS-Devel] [ opensips-Bugs-2523454 ] Error in handling rls
	NOTIFY
Message-ID: <E1LbvX4-00040T-GE@565xhf1.ch3.sourceforge.com>

Bugs item #2523454, was opened at 2009-01-20 13:55
Message generated for change (Comment added) made by anca_vamanu
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=2523454&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: Nathan (rmnathan)
Assigned to: Anca Vamanu (anca_vamanu)
Summary: Error in handling rls NOTIFY

Initial Comment:
Hi
The following error message are printed while handling rls notify.
Jan 20 06:45:44 [7833] ERROR:rls:parse_subs_state: terminated state and no reason foundJan 20 06:45:44 [7833] ERROR:rls:rls_handle_notify: while parsing 'Subscription-State' header
Jan 20 06:45:44 [7833] ERROR:rls:parse_subs_state: terminated state and no reason foundJan 20 06:45:44 [7833] ERROR:rls:rls_handle_notify: while parsing 'Subscription-State' header
Jan 20 06:45:44 [7833] ERROR:rls:parse_subs_state: terminated state and no reason foundJan 20 06:45:44 [7833] ERROR:rls:rls_handle_notify: while parsing 'Subscription-State' header
Jan 20 06:45:52 [7833] ERROR:rls:parse_subs_state: terminated state and no reason foundJan 20 06:45:52 [7833] ERROR:rls:rls_handle_notify: while parsing 'Subscription-State' header
Jan 20 06:45:52 [7833] ERROR:rls:parse_subs_state: terminated state and no reason foundJan 20 06:45:52 [7833] ERROR:rls:rls_handle_notify: while parsing 'Subscription-State' header
Jan 20 06:46:13 [7834] ERROR:core:db_do_insert: invalid parameter value
Jan 20 06:46:13 [7834] ERROR:pua:db_update: while inserting in db table pua
Jan 20 06:46:43 [7834] ERROR:core:parse_uri: uri too short: <> (0)
Jan 20 06:46:43 [7834] ERROR:tm:uri2proxy: bad_uri:
Jan 20 06:46:43 [7834] ERROR:tm:uri2su: failed create a dst proxy
Jan 20 06:46:43 [7834] ERROR:tm:t_uac: no socket found
Jan 20 06:46:43 [7834] ERROR:pua:update_pua: in t_request function
Jan 20 06:46:43 [7834] ERROR:pua:hashT_clean: while updating record
Jan 20 06:47:05 [7833] ERROR:rls:parse_subs_state: terminated state and no reason foundJan 20 06:47:05 [7833] ERROR:rls:rls_handle_notify: while parsing 'Subscription-State' header

Regards,
rmnathan


----------------------------------------------------------------------

>Comment By: Anca Vamanu (anca_vamanu)
Date: 2009-02-24 13:33

Message:
Hi Rmnathan,

What is the exact role of this scscf? Does is send Notifies with the state
of the clients? 
Please look in the trace that you sent and tell me who sends the Notify
number 119.

regards,
Anca

----------------------------------------------------------------------

Comment By: Nathan (rmnathan)
Date: 2009-02-24 06:31

Message:
Hi
This is also scscf only. it is multiple process running on 192.168.166.150
with different ports for each process (ie for each user).

Thanks
rmnathan

----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2009-02-24 06:30

Message:
Hi
This is also scscf only. it is multiple process running on 192.168.166.150
with different ports for each process (ie for each user).

Thanks
rmnathan

----------------------------------------------------------------------

Comment By: Anca Vamanu (anca_vamanu)
Date: 2009-02-20 14:09

Message:
Hi,

Can you tell me also what's running at 192.168.166.150:50607? 

thanks,
Anca

----------------------------------------------------------------------

Comment By: Nathan (rmnathan)
Date: 2009-02-20 12:28

Message:
Hi Anca,
You are correct . That is not presence or rls server. It is registrar
(scscf) running on 192.168.166.150:50606. 
Please let me know if you want any information.

Thanks lot
rmnathan

----------------------------------------------------------------------

Comment By: Anca Vamanu (anca_vamanu)
Date: 2009-02-19 14:03

Message:
Hi Rmnathan,

I looked through your trace but something is confusing.
Can you please tell me what was running on 192.168.166.150 port 50606. I
see that the User-Agent header is OpenSIPS, but the behavior doesn't seem
like that of a presence or rls server.

regards,
Anca

----------------------------------------------------------------------

Comment By: Nathan (rmnathan)
Date: 2009-02-02 11:14

Message:
Hi Anca.
Yes, am using opensips as presence server and rls server. Please find the
logs and pcap file for call flow attached.

Regards,
rmnathan


----------------------------------------------------------------------

Comment By: Anca Vamanu (anca_vamanu)
Date: 2009-01-22 15:25

Message:
Hi rmnathan,

Thank you for this report also.
There is something wrong with that Notify that gives this error.
Can you please trace the trafic and catch a Notify that generates this
error and print it here?
This Notify is received from the presence server. Are you using also
OpenSIPS as the presence server? Can you please check is the source IP
address of the Notify message is that of the presence server?

regards,
Anca

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=2523454&group_id=232389


From noreply at sourceforge.net  Tue Feb 24 13:01:57 2009
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 24 Feb 2009 12:01:57 +0000
Subject: [OpenSIPS-Devel] [ opensips-Bugs-2633350 ] Crash in dialog
	module+patch
Message-ID: <E1Lbvz3-0005b3-LW@155xhf1.ch3.sourceforge.com>

Bugs item #2633350, was opened at 2009-02-24 14:01
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=2633350&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: Vasil Kolev (krokodilerian)
Assigned to: Nobody/Anonymous (nobody)
Summary: Crash in dialog module+patch

Initial Comment:
When using the dialog module with realtime db usage, it crashes with the following backtrace:

(gdb) bt
#0  0xb77f9104 in update_dialog_dbinfo (cell=0xb57ba410) at dlg_db_handler.c:511
#1  0xb7800370 in dlg_onreply (t=0xb57b0db8, type=128, param=0xb78c1b34) at dlg_handlers.c:323
#2  0xb789d22b in run_trans_callbacks (type=128, trans=0xb57b0db8, req=0xb57bb6f0, rpl=0xffffffff, code=200) at t_hooks.c:208
#3  0xb78b2cf3 in _reply_light (trans=0xb57b0db8, 
    buf=0x819f428 "SIP/2.0 200 OK\r\nVia: SIP/2.0/UDP 89.253.129.130:27819;branch=z9hG4bK-d8754z-cb4ec1c38ba46444-1---d8754z-;rport=27819\r\nTo: <sip:vasil.kolev%40securax.org at sip.zoiper.com;transport=UDP>;tag=945b7285134e5"..., len=<value optimized out>, code=200, to_tag=0xb78d2a40 "945b7285134e5709ca8a0d8ffb065070-ab6d", to_tag_len=37, lock=1, bm=0xbfd0106c) at t_reply.c:373
#4  0xb78b3425 in _reply (trans=0xb57b0db8, p_msg=<value optimized out>, code=200, text=0xb77a4b08, lock=1) at t_reply.c:446
#5  0xb78a75ba in w_t_reply (msg=0x819dfb0, str1=0xc8 <Address 0xc8 out of bounds>, str2=0xb77a4b08 ">\az?\002") at tm.c:863
#6  0xb7d5beba in sig_send_reply_mod (msg=0x819dfb0, code=200, reason=0xb77a4b08, to_tag=0xbfd012f8) at signaling.c:178
#7  0xb779708a in send_2XX_reply (msg=0x819dfb0, reply_code=200, lexpire=<value optimized out>, rtag=0xbfd012f8, local_contact=0xbfd01324) at subscribe.c:112
#8  0xb7797d72 in update_subscription (msg=0x819dfb0, subs=0xbfd012c4, init_req=1) at subscribe.c:378
#9  0xb779c72b in handle_subscribe (msg=0x819dfb0, str1=0x0, str2=0x0) at subscribe.c:699
#10 0x08055591 in do_action (a=0x8196618, msg=0x819dfb0) at action.c:961
#11 0x080541e2 in run_action_list (a=0x8196618, msg=0x819dfb0) at action.c:139
#12 0x08056ecd in do_action (a=0x8197550, msg=0x819dfb0) at action.c:705
#13 0x080541e2 in run_action_list (a=0x8197550, msg=0x819dfb0) at action.c:139
#14 0x08057529 in do_action (a=0x81975b8, msg=0x819dfb0) at action.c:711
#15 0x080541e2 in run_action_list (a=0x81960a8, msg=0x819dfb0) at action.c:139
#16 0x08056914 in do_action (a=0x81934e0, msg=0x819dfb0) at action.c:119
#17 0x080541e2 in run_action_list (a=0x81934e0, msg=0x819dfb0) at action.c:139
#18 0x08056ecd in do_action (a=0x8193548, msg=0x819dfb0) at action.c:705
#19 0x080541e2 in run_action_list (a=0x818e390, msg=0x819dfb0) at action.c:139
#20 0x08057ee1 in run_top_route (a=0x818e390, msg=0x819dfb0) at action.c:119
#21 0x0809228c in receive_msg (
    buf=0x8164220 "SUBSCRIBE sip:vasil.kolev%40securax.org at sip.zoiper.com;transport=UDP SIP/2.0\r\nVia: SIP/2.0/UDP 89.253.129.130:27819;branch=z9hG4bK-d8754z-cb4ec1c38ba46444-1---d8754z-;rport\r\nMax-Forwards: 69\r\nContact:"..., len=933, rcv_info=0xbfd020a4) at receive.c:165
#22 0x080cdf4b in udp_rcv_loop () at udp_server.c:449
#23 0x0806c3af in main (argc=1, argv=0xbfd02234) at main.c:778


When investigating it, turned out that cell->bind_addr[DLG_CALLEE_LEG] is NULL, and while trying to dereference that to get the sock_str, it crashes. I added a check and a specific str null_element to update it right.

Also, there was a strange typo in the LM_DBG there, it was using the value from the cell->bind_addr[DLG_CALLEE_LEG]->sock_str, but the length from cell->bind_addr[DLG_CALLER_LEG]->sock_str.

Patch attached (against trunk).

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=2633350&group_id=232389


From noreply at sourceforge.net  Tue Feb 24 13:12:45 2009
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 24 Feb 2009 12:12:45 +0000
Subject: [OpenSIPS-Devel] [ opensips-Bugs-2523454 ] Error in handling rls
	NOTIFY
Message-ID: <E1Lbw9V-0001lk-3J@3bkjzd1.ch3.sourceforge.com>

Bugs item #2523454, was opened at 2009-01-20 17:25
Message generated for change (Comment added) made by rmnathan
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=2523454&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: Nathan (rmnathan)
Assigned to: Anca Vamanu (anca_vamanu)
Summary: Error in handling rls NOTIFY

Initial Comment:
Hi
The following error message are printed while handling rls notify.
Jan 20 06:45:44 [7833] ERROR:rls:parse_subs_state: terminated state and no reason foundJan 20 06:45:44 [7833] ERROR:rls:rls_handle_notify: while parsing 'Subscription-State' header
Jan 20 06:45:44 [7833] ERROR:rls:parse_subs_state: terminated state and no reason foundJan 20 06:45:44 [7833] ERROR:rls:rls_handle_notify: while parsing 'Subscription-State' header
Jan 20 06:45:44 [7833] ERROR:rls:parse_subs_state: terminated state and no reason foundJan 20 06:45:44 [7833] ERROR:rls:rls_handle_notify: while parsing 'Subscription-State' header
Jan 20 06:45:52 [7833] ERROR:rls:parse_subs_state: terminated state and no reason foundJan 20 06:45:52 [7833] ERROR:rls:rls_handle_notify: while parsing 'Subscription-State' header
Jan 20 06:45:52 [7833] ERROR:rls:parse_subs_state: terminated state and no reason foundJan 20 06:45:52 [7833] ERROR:rls:rls_handle_notify: while parsing 'Subscription-State' header
Jan 20 06:46:13 [7834] ERROR:core:db_do_insert: invalid parameter value
Jan 20 06:46:13 [7834] ERROR:pua:db_update: while inserting in db table pua
Jan 20 06:46:43 [7834] ERROR:core:parse_uri: uri too short: <> (0)
Jan 20 06:46:43 [7834] ERROR:tm:uri2proxy: bad_uri:
Jan 20 06:46:43 [7834] ERROR:tm:uri2su: failed create a dst proxy
Jan 20 06:46:43 [7834] ERROR:tm:t_uac: no socket found
Jan 20 06:46:43 [7834] ERROR:pua:update_pua: in t_request function
Jan 20 06:46:43 [7834] ERROR:pua:hashT_clean: while updating record
Jan 20 06:47:05 [7833] ERROR:rls:parse_subs_state: terminated state and no reason foundJan 20 06:47:05 [7833] ERROR:rls:rls_handle_notify: while parsing 'Subscription-State' header

Regards,
rmnathan


----------------------------------------------------------------------

Comment By: Nathan (rmnathan)
Date: 2009-02-24 17:42

Message:
Hi Anca,
can you please send me your mail id or IM id to discuss the issue? 
Regards
rmnathan

----------------------------------------------------------------------

Comment By: Anca Vamanu (anca_vamanu)
Date: 2009-02-24 17:03

Message:
Hi Rmnathan,

What is the exact role of this scscf? Does is send Notifies with the state
of the clients? 
Please look in the trace that you sent and tell me who sends the Notify
number 119.

regards,
Anca

----------------------------------------------------------------------

Comment By: Nathan (rmnathan)
Date: 2009-02-24 10:01

Message:
Hi
This is also scscf only. it is multiple process running on 192.168.166.150
with different ports for each process (ie for each user).

Thanks
rmnathan

----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2009-02-24 10:00

Message:
Hi
This is also scscf only. it is multiple process running on 192.168.166.150
with different ports for each process (ie for each user).

Thanks
rmnathan

----------------------------------------------------------------------

Comment By: Anca Vamanu (anca_vamanu)
Date: 2009-02-20 17:39

Message:
Hi,

Can you tell me also what's running at 192.168.166.150:50607? 

thanks,
Anca

----------------------------------------------------------------------

Comment By: Nathan (rmnathan)
Date: 2009-02-20 15:58

Message:
Hi Anca,
You are correct . That is not presence or rls server. It is registrar
(scscf) running on 192.168.166.150:50606. 
Please let me know if you want any information.

Thanks lot
rmnathan

----------------------------------------------------------------------

Comment By: Anca Vamanu (anca_vamanu)
Date: 2009-02-19 17:33

Message:
Hi Rmnathan,

I looked through your trace but something is confusing.
Can you please tell me what was running on 192.168.166.150 port 50606. I
see that the User-Agent header is OpenSIPS, but the behavior doesn't seem
like that of a presence or rls server.

regards,
Anca

----------------------------------------------------------------------

Comment By: Nathan (rmnathan)
Date: 2009-02-02 14:44

Message:
Hi Anca.
Yes, am using opensips as presence server and rls server. Please find the
logs and pcap file for call flow attached.

Regards,
rmnathan


----------------------------------------------------------------------

Comment By: Anca Vamanu (anca_vamanu)
Date: 2009-01-22 18:55

Message:
Hi rmnathan,

Thank you for this report also.
There is something wrong with that Notify that gives this error.
Can you please trace the trafic and catch a Notify that generates this
error and print it here?
This Notify is received from the presence server. Are you using also
OpenSIPS as the presence server? Can you please check is the source IP
address of the Notify message is that of the presence server?

regards,
Anca

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=2523454&group_id=232389


From noreply at sourceforge.net  Tue Feb 24 13:52:39 2009
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 24 Feb 2009 12:52:39 +0000
Subject: [OpenSIPS-Devel] [ opensips-Bugs-2591935 ] Error in sending NOTIFY
	for PUBLISH in RLS mode
Message-ID: <E1Lbwm7-0004YT-KD@g45xhf1.ch3.sourceforge.com>

Bugs item #2591935, was opened at 2009-02-12 08:31
Message generated for change (Comment added) made by anca_vamanu
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=2591935&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: Nathan (rmnathan)
Assigned to: Anca Vamanu (anca_vamanu)
Summary: Error in sending NOTIFY for PUBLISH in RLS mode

Initial Comment:
Hi
When opensips got publish for the user(say E1_1) which has in two list subscriptions, it is sending notify to one user only.
For example:
UE2_1 list will have 2 entry uri like E1_1,E1_2
UE2_2 list will have 2 entry uri like E1_2,E1_1

S2_1 subscribe to UE2_1
S2_2 subscribe to UE2_2
If E1_1 send publish, opensips sends notify to S2_1 only. But it should send notify to S2_2 too.

Please find the attached pcap file for detailed call flow.

Regards,
rmnathan


----------------------------------------------------------------------

>Comment By: Anca Vamanu (anca_vamanu)
Date: 2009-02-24 14:52

Message:
Hi Rmnathan,

If you really want to help me figure out what your problem is you have to
send simpler traces. Your trace is impossible to analize - you have 8 lists
with different names, but there are 4 pairs having the same content - so
there are actually only 4 unique lists. Then you use in 'From' header of
the SUBSCRIBE not the name of the list but anther uri - this is not
important in the SIP logic - but it makes impossible for me to follow the
messages since the Notifies that the RLS sends and receives will have the
same To and From headers.
Please if you want to help run a simpler case - only two Subscriptions to
lists that can have different names but the same content. 
One more question - do you use a presence server that receives the
Subscribe messages sent by the rls server and also Publish messages from
the clients? Or you send the Subscribes directly to the clients and they
reply with Notifies?
Please also include a description with the entities in the scenario and
the IP address and port they run at.

Thanks,
Anca


----------------------------------------------------------------------

Comment By: Anca Vamanu (anca_vamanu)
Date: 2009-02-24 13:29

Message:
Hi Rmnathan,

If you really want to help me figure out what your problem is you have to
send simpler traces. Your trace is impossible to analize - you have 8 lists
with different names, but there are 4 pairs having the same content - so
there are actually only 4 unique lists. Then you use in 'From' header of
the SUBSCRIBE not the name of the list but anther uri - this is not
important in the SIP logic - but it makes impossible for me to follow the
messages since the Notifies that the RLS sends and receives will have the
same To and From headers.
Please if you want to help run a simpler case - only two Subscriptions to
lists that can have different names but the same content. 
One more question - do you use a presence server that receives the
Subscribe messages sent by the rls server and also Publish messages from
the clients? Or you send the Subscribes directly to the clients and they
reply with Notifies?
Please also include a description with the entities in the scenario and
the IP address and port they run at.

Thanks,
Anca


----------------------------------------------------------------------

Comment By: Nathan (rmnathan)
Date: 2009-02-24 12:43

Message:
Hi Anca,
After that i have tested. still the issue is not fixed. Now opensips is
generating notify for all the users(for first user) in the list but it
always sending to first user in the list only not for other users. 

Please see the attached pcap file.

Regards
rmnathan



----------------------------------------------------------------------

Comment By: Anca Vamanu (anca_vamanu)
Date: 2009-02-24 11:49

Message:
Hi Rmnathan,

A change was made for many tables - changing varchar type to char and
since the structure was changed, the version of the tables was increased.
You need to get the new mysql script and recreate the table and also
update the version for rls_presentity table in 'version' table. However
since there are many tables for which the version was increased I would
recommend recreating the whole database.

regards,
Anca

----------------------------------------------------------------------

Comment By: Nathan (rmnathan)
Date: 2009-02-24 08:23

Message:
Hi Anca,
I tried with latest trunk 5354 build. while starting opensips i got
following error message
stinbng46:/usr/local/trunk# /usr/local/sbin/opensips
Listening on
             udp: 10.6.2.246 [10.6.2.246]:5060
Aliases:
             udp: stinbng46:5060

stinbng46:/usr/local/trunk# Feb 24 11:46:35 [2520]
ERROR:core:db_check_table_version: invalid version 0 for table
rls_presentity found, expected 1
Feb 24 11:46:35 [2520] ERROR:rls:mod_init: error during table version
check.
Feb 24 11:46:35 [2520] ERROR:core:init_mod: failed to initialize module
rls
Feb 24 11:46:35 [2520] ERROR:core:main: error while initializing modules
i have   rls_presentity table also in opensips database.
mysql> desc rls_presentity
    -> ;
+----------------+------------------+------+-----+---------+----------------+
| Field          | Type             | Null | Key | Default | Extra        
 |
+----------------+------------------+------+-----+---------+----------------+
| id             | int(10) unsigned | NO   | PRI | NULL    |
auto_increment |
| rlsubs_did     | char(255)        | NO   | MUL |         |              
 |
| resource_uri   | char(128)        | NO   |     |         |              
 |
| content_type   | char(64)         | NO   |     |         |              
 |
| presence_state | blob             | NO   |     |         |              
 |
| expires        | int(11)          | NO   |     |         |              
 |
| updated        | int(11)          | NO   | MUL |         |              
 |
| auth_state     | int(11)          | NO   |     |         |              
 |
| reason         | char(64)         | NO   |     |         |              
 |
+----------------+------------------+------+-----+---------+----------------+
9 rows in set (0.00 sec)

I have changed and tried table version in script also 
INSERT INTO version (table_name, table_version) values
('rls_presentity','1');
  CREATE TABLE rls_presentity (
      id INT(10) UNSIGNED AUTO_INCREMENT PRIMARY KEY NOT NULL,
      rlsubs_did CHAR(255) NOT NULL,
      resource_uri CHAR(128) NOT NULL,
      content_type CHAR(64) NOT NULL,
      presence_state BLOB NOT NULL,
      expires INT(11) NOT NULL,
      updated INT(11) NOT NULL,
      auth_state INT(11) NOT NULL,
      reason CHAR(64) NOT NULL,
      CONSTRAINT rls_presentity_idx UNIQUE (rlsubs_did, resource_uri)
  ) ENGINE=MyISAM;
Again i got the same error.

Regards
rmnathan

----------------------------------------------------------------------

Comment By: Anca Vamanu (anca_vamanu)
Date: 2009-02-18 17:17

Message:
Hi Rmnathan,

Thank you for this report.
Indeed, you were right- not all update Notifies were sent due to a bug in
the code. I have fixed it. Please update to the new svn version and test it
yourself. I will wait for your feedback before closing this bug report.

regards,
Anca



----------------------------------------------------------------------

Comment By: Anca Vamanu (anca_vamanu)
Date: 2009-02-18 17:17

Message:
Hi Rmnathan,

Thank you for this report.
Indeed, you were right- not all update Notifies were sent due to a bug in
the code. I have fixed it. Please update to the new svn version and test it
yourself. I will wait for your feedback before closing this bug report.

regards,
Anca



----------------------------------------------------------------------

Comment By: Anca Vamanu (anca_vamanu)
Date: 2009-02-18 17:16

Message:
Hi Rmnathan,

Thank you for this report.
Indeed, you were right- not all update Notifies were sent due to a bug in
the code. I have fixed it. Please update to the new svn version and test it
yourself. I will wait for your feedback before closing this bug report.

regards,
Anca



----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=2591935&group_id=232389


From noreply at sourceforge.net  Tue Feb 24 13:55:11 2009
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 24 Feb 2009 12:55:11 +0000
Subject: [OpenSIPS-Devel] [ opensips-Bugs-2523454 ] Error in handling rls
	NOTIFY
Message-ID: <E1LbwoZ-00047x-BR@d45xhf1.ch3.sourceforge.com>

Bugs item #2523454, was opened at 2009-01-20 13:55
Message generated for change (Comment added) made by anca_vamanu
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=2523454&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: Nathan (rmnathan)
Assigned to: Anca Vamanu (anca_vamanu)
Summary: Error in handling rls NOTIFY

Initial Comment:
Hi
The following error message are printed while handling rls notify.
Jan 20 06:45:44 [7833] ERROR:rls:parse_subs_state: terminated state and no reason foundJan 20 06:45:44 [7833] ERROR:rls:rls_handle_notify: while parsing 'Subscription-State' header
Jan 20 06:45:44 [7833] ERROR:rls:parse_subs_state: terminated state and no reason foundJan 20 06:45:44 [7833] ERROR:rls:rls_handle_notify: while parsing 'Subscription-State' header
Jan 20 06:45:44 [7833] ERROR:rls:parse_subs_state: terminated state and no reason foundJan 20 06:45:44 [7833] ERROR:rls:rls_handle_notify: while parsing 'Subscription-State' header
Jan 20 06:45:52 [7833] ERROR:rls:parse_subs_state: terminated state and no reason foundJan 20 06:45:52 [7833] ERROR:rls:rls_handle_notify: while parsing 'Subscription-State' header
Jan 20 06:45:52 [7833] ERROR:rls:parse_subs_state: terminated state and no reason foundJan 20 06:45:52 [7833] ERROR:rls:rls_handle_notify: while parsing 'Subscription-State' header
Jan 20 06:46:13 [7834] ERROR:core:db_do_insert: invalid parameter value
Jan 20 06:46:13 [7834] ERROR:pua:db_update: while inserting in db table pua
Jan 20 06:46:43 [7834] ERROR:core:parse_uri: uri too short: <> (0)
Jan 20 06:46:43 [7834] ERROR:tm:uri2proxy: bad_uri:
Jan 20 06:46:43 [7834] ERROR:tm:uri2su: failed create a dst proxy
Jan 20 06:46:43 [7834] ERROR:tm:t_uac: no socket found
Jan 20 06:46:43 [7834] ERROR:pua:update_pua: in t_request function
Jan 20 06:46:43 [7834] ERROR:pua:hashT_clean: while updating record
Jan 20 06:47:05 [7833] ERROR:rls:parse_subs_state: terminated state and no reason foundJan 20 06:47:05 [7833] ERROR:rls:rls_handle_notify: while parsing 'Subscription-State' header

Regards,
rmnathan


----------------------------------------------------------------------

>Comment By: Anca Vamanu (anca_vamanu)
Date: 2009-02-24 14:55

Message:
Hi,

You can send me an e-mail at anca at opensips.org.

Anca

----------------------------------------------------------------------

Comment By: Nathan (rmnathan)
Date: 2009-02-24 14:12

Message:
Hi Anca,
can you please send me your mail id or IM id to discuss the issue? 
Regards
rmnathan

----------------------------------------------------------------------

Comment By: Anca Vamanu (anca_vamanu)
Date: 2009-02-24 13:33

Message:
Hi Rmnathan,

What is the exact role of this scscf? Does is send Notifies with the state
of the clients? 
Please look in the trace that you sent and tell me who sends the Notify
number 119.

regards,
Anca

----------------------------------------------------------------------

Comment By: Nathan (rmnathan)
Date: 2009-02-24 06:31

Message:
Hi
This is also scscf only. it is multiple process running on 192.168.166.150
with different ports for each process (ie for each user).

Thanks
rmnathan

----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2009-02-24 06:30

Message:
Hi
This is also scscf only. it is multiple process running on 192.168.166.150
with different ports for each process (ie for each user).

Thanks
rmnathan

----------------------------------------------------------------------

Comment By: Anca Vamanu (anca_vamanu)
Date: 2009-02-20 14:09

Message:
Hi,

Can you tell me also what's running at 192.168.166.150:50607? 

thanks,
Anca

----------------------------------------------------------------------

Comment By: Nathan (rmnathan)
Date: 2009-02-20 12:28

Message:
Hi Anca,
You are correct . That is not presence or rls server. It is registrar
(scscf) running on 192.168.166.150:50606. 
Please let me know if you want any information.

Thanks lot
rmnathan

----------------------------------------------------------------------

Comment By: Anca Vamanu (anca_vamanu)
Date: 2009-02-19 14:03

Message:
Hi Rmnathan,

I looked through your trace but something is confusing.
Can you please tell me what was running on 192.168.166.150 port 50606. I
see that the User-Agent header is OpenSIPS, but the behavior doesn't seem
like that of a presence or rls server.

regards,
Anca

----------------------------------------------------------------------

Comment By: Nathan (rmnathan)
Date: 2009-02-02 11:14

Message:
Hi Anca.
Yes, am using opensips as presence server and rls server. Please find the
logs and pcap file for call flow attached.

Regards,
rmnathan


----------------------------------------------------------------------

Comment By: Anca Vamanu (anca_vamanu)
Date: 2009-01-22 15:25

Message:
Hi rmnathan,

Thank you for this report also.
There is something wrong with that Notify that gives this error.
Can you please trace the trafic and catch a Notify that generates this
error and print it here?
This Notify is received from the presence server. Are you using also
OpenSIPS as the presence server? Can you please check is the source IP
address of the Notify message is that of the presence server?

regards,
Anca

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=2523454&group_id=232389


From noreply at sourceforge.net  Tue Feb 24 14:37:20 2009
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 24 Feb 2009 13:37:20 +0000
Subject: [OpenSIPS-Devel] [ opensips-Bugs-2591935 ] Error in sending NOTIFY
	for PUBLISH in RLS mode
Message-ID: <E1LbxTM-0003yF-1j@155xhf1.ch3.sourceforge.com>

Bugs item #2591935, was opened at 2009-02-12 12:01
Message generated for change (Comment added) made by rmnathan
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=2591935&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: Nathan (rmnathan)
Assigned to: Anca Vamanu (anca_vamanu)
Summary: Error in sending NOTIFY for PUBLISH in RLS mode

Initial Comment:
Hi
When opensips got publish for the user(say E1_1) which has in two list subscriptions, it is sending notify to one user only.
For example:
UE2_1 list will have 2 entry uri like E1_1,E1_2
UE2_2 list will have 2 entry uri like E1_2,E1_1

S2_1 subscribe to UE2_1
S2_2 subscribe to UE2_2
If E1_1 send publish, opensips sends notify to S2_1 only. But it should send notify to S2_2 too.

Please find the attached pcap file for detailed call flow.

Regards,
rmnathan


----------------------------------------------------------------------

Comment By: Nathan (rmnathan)
Date: 2009-02-24 19:07

Message:
Hi Anca

Test setup description:
======================

IMS UE1
192.168.165.151:5070
				Proxy - SCSCF            ----  Opensips(presence server)   ---- RLS
server
			  (192.168.166.150:50602)	       (10.6.2.246:5060)               
(10.6.2.246:5060)
IMS UE2
192.168.165.152:5075


IMS UE1 has two users 
1.c3-1 which has s3-1 in list

<?xml version="1.0" encoding="UTF-8"?>
 <rls-services>
 <service uri="sip:c3-1_list at 10.6.2.246">
   <list name="c3-1">
    <entry uri="sip:s3-1 at 10.6.2.246"/>

   </list>
   <packages>
    <package>presence</package>
   </packages>
  </service>
 </rls-services>

2.c3-2 which has also s3-1 in list

<?xml version="1.0" encoding="UTF-8"?>
 <rls-services>
 <service uri="sip:c3-2_list at 10.6.2.246">
   <list name="c3-2">
    <entry uri="sip:s3-1 at 10.6.2.246"/>

   </list>
   <packages>
    <package>presence</package>
   </packages>
  </service>
 </rls-services>

IMS UE2 has one user
1.s3-1 ( this is only to send publish)


call flow description
=====================
1.IMS UE1 ie(c3-1 and c3-2) will send subcribe to their list
2. Presence server that receives the Subscribe messages sent by the rls
server for the list subscription because the users
  in the list are same domain of presence server. So RLS server sends
subscribe, 200 ok for subscribe , Notify and 200 ok
  for notify to presence server(ie to itself because opensips and RLS
server running on same IP: 10.6.2.246)
3. After got 200 ok for subscribe and notify  for IMS UE1 users
4. Send subscribe from IMS UE2 (ie s3-1 to c3-1) . This is just to send
publish.
5. Then send publish from s3-1 ie from IMS UE2. 
6. After got publish RLS server should generate notify to c3-1 and c3-2
because c3-1 & c3-2 have subscribed to s3-1 
7. From captured trace RLS server sends notify and 200 ok for notify to
presence server (please explain why this is sending notify to opensips)
8. Then after that RLS sends notify to IMS UE1

9. refreshed Publish from IMS UE2
10 Removed Publish  from IMS UE2


For your queries
================
do you use a presence server that receives the
Subscribe messages sent by the rls server and also Publish messages from
the clients?

yes presence server receives the subscribe messages sent by the rls
server. The publish from clients (in this case from s3-1 (IMS UE2)

2.you send the Subscribes directly to the clients and they
reply with Notifies?
No. the subscribes sends to presence server by the rls server.

Please let me know if you want more information.
Please find captured trace also.

Regards
rmnathan


----------------------------------------------------------------------

Comment By: Anca Vamanu (anca_vamanu)
Date: 2009-02-24 18:22

Message:
Hi Rmnathan,

If you really want to help me figure out what your problem is you have to
send simpler traces. Your trace is impossible to analize - you have 8 lists
with different names, but there are 4 pairs having the same content - so
there are actually only 4 unique lists. Then you use in 'From' header of
the SUBSCRIBE not the name of the list but anther uri - this is not
important in the SIP logic - but it makes impossible for me to follow the
messages since the Notifies that the RLS sends and receives will have the
same To and From headers.
Please if you want to help run a simpler case - only two Subscriptions to
lists that can have different names but the same content. 
One more question - do you use a presence server that receives the
Subscribe messages sent by the rls server and also Publish messages from
the clients? Or you send the Subscribes directly to the clients and they
reply with Notifies?
Please also include a description with the entities in the scenario and
the IP address and port they run at.

Thanks,
Anca


----------------------------------------------------------------------

Comment By: Anca Vamanu (anca_vamanu)
Date: 2009-02-24 16:59

Message:
Hi Rmnathan,

If you really want to help me figure out what your problem is you have to
send simpler traces. Your trace is impossible to analize - you have 8 lists
with different names, but there are 4 pairs having the same content - so
there are actually only 4 unique lists. Then you use in 'From' header of
the SUBSCRIBE not the name of the list but anther uri - this is not
important in the SIP logic - but it makes impossible for me to follow the
messages since the Notifies that the RLS sends and receives will have the
same To and From headers.
Please if you want to help run a simpler case - only two Subscriptions to
lists that can have different names but the same content. 
One more question - do you use a presence server that receives the
Subscribe messages sent by the rls server and also Publish messages from
the clients? Or you send the Subscribes directly to the clients and they
reply with Notifies?
Please also include a description with the entities in the scenario and
the IP address and port they run at.

Thanks,
Anca


----------------------------------------------------------------------

Comment By: Nathan (rmnathan)
Date: 2009-02-24 16:13

Message:
Hi Anca,
After that i have tested. still the issue is not fixed. Now opensips is
generating notify for all the users(for first user) in the list but it
always sending to first user in the list only not for other users. 

Please see the attached pcap file.

Regards
rmnathan



----------------------------------------------------------------------

Comment By: Anca Vamanu (anca_vamanu)
Date: 2009-02-24 15:19

Message:
Hi Rmnathan,

A change was made for many tables - changing varchar type to char and
since the structure was changed, the version of the tables was increased.
You need to get the new mysql script and recreate the table and also
update the version for rls_presentity table in 'version' table. However
since there are many tables for which the version was increased I would
recommend recreating the whole database.

regards,
Anca

----------------------------------------------------------------------

Comment By: Nathan (rmnathan)
Date: 2009-02-24 11:53

Message:
Hi Anca,
I tried with latest trunk 5354 build. while starting opensips i got
following error message
stinbng46:/usr/local/trunk# /usr/local/sbin/opensips
Listening on
             udp: 10.6.2.246 [10.6.2.246]:5060
Aliases:
             udp: stinbng46:5060

stinbng46:/usr/local/trunk# Feb 24 11:46:35 [2520]
ERROR:core:db_check_table_version: invalid version 0 for table
rls_presentity found, expected 1
Feb 24 11:46:35 [2520] ERROR:rls:mod_init: error during table version
check.
Feb 24 11:46:35 [2520] ERROR:core:init_mod: failed to initialize module
rls
Feb 24 11:46:35 [2520] ERROR:core:main: error while initializing modules
i have   rls_presentity table also in opensips database.
mysql> desc rls_presentity
    -> ;
+----------------+------------------+------+-----+---------+----------------+
| Field          | Type             | Null | Key | Default | Extra        
 |
+----------------+------------------+------+-----+---------+----------------+
| id             | int(10) unsigned | NO   | PRI | NULL    |
auto_increment |
| rlsubs_did     | char(255)        | NO   | MUL |         |              
 |
| resource_uri   | char(128)        | NO   |     |         |              
 |
| content_type   | char(64)         | NO   |     |         |              
 |
| presence_state | blob             | NO   |     |         |              
 |
| expires        | int(11)          | NO   |     |         |              
 |
| updated        | int(11)          | NO   | MUL |         |              
 |
| auth_state     | int(11)          | NO   |     |         |              
 |
| reason         | char(64)         | NO   |     |         |              
 |
+----------------+------------------+------+-----+---------+----------------+
9 rows in set (0.00 sec)

I have changed and tried table version in script also 
INSERT INTO version (table_name, table_version) values
('rls_presentity','1');
  CREATE TABLE rls_presentity (
      id INT(10) UNSIGNED AUTO_INCREMENT PRIMARY KEY NOT NULL,
      rlsubs_did CHAR(255) NOT NULL,
      resource_uri CHAR(128) NOT NULL,
      content_type CHAR(64) NOT NULL,
      presence_state BLOB NOT NULL,
      expires INT(11) NOT NULL,
      updated INT(11) NOT NULL,
      auth_state INT(11) NOT NULL,
      reason CHAR(64) NOT NULL,
      CONSTRAINT rls_presentity_idx UNIQUE (rlsubs_did, resource_uri)
  ) ENGINE=MyISAM;
Again i got the same error.

Regards
rmnathan

----------------------------------------------------------------------

Comment By: Anca Vamanu (anca_vamanu)
Date: 2009-02-18 20:47

Message:
Hi Rmnathan,

Thank you for this report.
Indeed, you were right- not all update Notifies were sent due to a bug in
the code. I have fixed it. Please update to the new svn version and test it
yourself. I will wait for your feedback before closing this bug report.

regards,
Anca



----------------------------------------------------------------------

Comment By: Anca Vamanu (anca_vamanu)
Date: 2009-02-18 20:47

Message:
Hi Rmnathan,

Thank you for this report.
Indeed, you were right- not all update Notifies were sent due to a bug in
the code. I have fixed it. Please update to the new svn version and test it
yourself. I will wait for your feedback before closing this bug report.

regards,
Anca



----------------------------------------------------------------------

Comment By: Anca Vamanu (anca_vamanu)
Date: 2009-02-18 20:46

Message:
Hi Rmnathan,

Thank you for this report.
Indeed, you were right- not all update Notifies were sent due to a bug in
the code. I have fixed it. Please update to the new svn version and test it
yourself. I will wait for your feedback before closing this bug report.

regards,
Anca



----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=2591935&group_id=232389


From noreply at sourceforge.net  Tue Feb 24 14:44:46 2009
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 24 Feb 2009 13:44:46 +0000
Subject: [OpenSIPS-Devel] [ opensips-Bugs-2591935 ] Error in sending NOTIFY
	for PUBLISH in RLS mode
Message-ID: <E1LbxaY-0005qQ-TA@h45xhf1.ch3.sourceforge.com>

Bugs item #2591935, was opened at 2009-02-12 12:01
Message generated for change (Comment added) made by rmnathan
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=2591935&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: Nathan (rmnathan)
Assigned to: Anca Vamanu (anca_vamanu)
Summary: Error in sending NOTIFY for PUBLISH in RLS mode

Initial Comment:
Hi
When opensips got publish for the user(say E1_1) which has in two list subscriptions, it is sending notify to one user only.
For example:
UE2_1 list will have 2 entry uri like E1_1,E1_2
UE2_2 list will have 2 entry uri like E1_2,E1_1

S2_1 subscribe to UE2_1
S2_2 subscribe to UE2_2
If E1_1 send publish, opensips sends notify to S2_1 only. But it should send notify to S2_2 too.

Please find the attached pcap file for detailed call flow.

Regards,
rmnathan


----------------------------------------------------------------------

>Comment By: Nathan (rmnathan)
Date: 2009-02-24 19:14

Message:
Hi,
Test setup details
IMS UE1 192.168.165.151:5070
IMS UE2  192.168.165.152:5075
Proxy - SCSCF (192.168.166.150:50602)
Opensips(presence server) (10.6.2.246:5060) 
RLS (10.6.2.246:5060)



----------------------------------------------------------------------

Comment By: Nathan (rmnathan)
Date: 2009-02-24 19:07

Message:
Hi Anca

Test setup description:
======================

IMS UE1
192.168.165.151:5070
				Proxy - SCSCF            ----  Opensips(presence server)   ---- RLS
server
			  (192.168.166.150:50602)	       (10.6.2.246:5060)               
(10.6.2.246:5060)
IMS UE2
192.168.165.152:5075


IMS UE1 has two users 
1.c3-1 which has s3-1 in list

<?xml version="1.0" encoding="UTF-8"?>
 <rls-services>
 <service uri="sip:c3-1_list at 10.6.2.246">
   <list name="c3-1">
    <entry uri="sip:s3-1 at 10.6.2.246"/>

   </list>
   <packages>
    <package>presence</package>
   </packages>
  </service>
 </rls-services>

2.c3-2 which has also s3-1 in list

<?xml version="1.0" encoding="UTF-8"?>
 <rls-services>
 <service uri="sip:c3-2_list at 10.6.2.246">
   <list name="c3-2">
    <entry uri="sip:s3-1 at 10.6.2.246"/>

   </list>
   <packages>
    <package>presence</package>
   </packages>
  </service>
 </rls-services>

IMS UE2 has one user
1.s3-1 ( this is only to send publish)


call flow description
=====================
1.IMS UE1 ie(c3-1 and c3-2) will send subcribe to their list
2. Presence server that receives the Subscribe messages sent by the rls
server for the list subscription because the users
  in the list are same domain of presence server. So RLS server sends
subscribe, 200 ok for subscribe , Notify and 200 ok
  for notify to presence server(ie to itself because opensips and RLS
server running on same IP: 10.6.2.246)
3. After got 200 ok for subscribe and notify  for IMS UE1 users
4. Send subscribe from IMS UE2 (ie s3-1 to c3-1) . This is just to send
publish.
5. Then send publish from s3-1 ie from IMS UE2. 
6. After got publish RLS server should generate notify to c3-1 and c3-2
because c3-1 & c3-2 have subscribed to s3-1 
7. From captured trace RLS server sends notify and 200 ok for notify to
presence server (please explain why this is sending notify to opensips)
8. Then after that RLS sends notify to IMS UE1

9. refreshed Publish from IMS UE2
10 Removed Publish  from IMS UE2


For your queries
================
do you use a presence server that receives the
Subscribe messages sent by the rls server and also Publish messages from
the clients?

yes presence server receives the subscribe messages sent by the rls
server. The publish from clients (in this case from s3-1 (IMS UE2)

2.you send the Subscribes directly to the clients and they
reply with Notifies?
No. the subscribes sends to presence server by the rls server.

Please let me know if you want more information.
Please find captured trace also.

Regards
rmnathan


----------------------------------------------------------------------

Comment By: Anca Vamanu (anca_vamanu)
Date: 2009-02-24 18:22

Message:
Hi Rmnathan,

If you really want to help me figure out what your problem is you have to
send simpler traces. Your trace is impossible to analize - you have 8 lists
with different names, but there are 4 pairs having the same content - so
there are actually only 4 unique lists. Then you use in 'From' header of
the SUBSCRIBE not the name of the list but anther uri - this is not
important in the SIP logic - but it makes impossible for me to follow the
messages since the Notifies that the RLS sends and receives will have the
same To and From headers.
Please if you want to help run a simpler case - only two Subscriptions to
lists that can have different names but the same content. 
One more question - do you use a presence server that receives the
Subscribe messages sent by the rls server and also Publish messages from
the clients? Or you send the Subscribes directly to the clients and they
reply with Notifies?
Please also include a description with the entities in the scenario and
the IP address and port they run at.

Thanks,
Anca


----------------------------------------------------------------------

Comment By: Anca Vamanu (anca_vamanu)
Date: 2009-02-24 16:59

Message:
Hi Rmnathan,

If you really want to help me figure out what your problem is you have to
send simpler traces. Your trace is impossible to analize - you have 8 lists
with different names, but there are 4 pairs having the same content - so
there are actually only 4 unique lists. Then you use in 'From' header of
the SUBSCRIBE not the name of the list but anther uri - this is not
important in the SIP logic - but it makes impossible for me to follow the
messages since the Notifies that the RLS sends and receives will have the
same To and From headers.
Please if you want to help run a simpler case - only two Subscriptions to
lists that can have different names but the same content. 
One more question - do you use a presence server that receives the
Subscribe messages sent by the rls server and also Publish messages from
the clients? Or you send the Subscribes directly to the clients and they
reply with Notifies?
Please also include a description with the entities in the scenario and
the IP address and port they run at.

Thanks,
Anca


----------------------------------------------------------------------

Comment By: Nathan (rmnathan)
Date: 2009-02-24 16:13

Message:
Hi Anca,
After that i have tested. still the issue is not fixed. Now opensips is
generating notify for all the users(for first user) in the list but it
always sending to first user in the list only not for other users. 

Please see the attached pcap file.

Regards
rmnathan



----------------------------------------------------------------------

Comment By: Anca Vamanu (anca_vamanu)
Date: 2009-02-24 15:19

Message:
Hi Rmnathan,

A change was made for many tables - changing varchar type to char and
since the structure was changed, the version of the tables was increased.
You need to get the new mysql script and recreate the table and also
update the version for rls_presentity table in 'version' table. However
since there are many tables for which the version was increased I would
recommend recreating the whole database.

regards,
Anca

----------------------------------------------------------------------

Comment By: Nathan (rmnathan)
Date: 2009-02-24 11:53

Message:
Hi Anca,
I tried with latest trunk 5354 build. while starting opensips i got
following error message
stinbng46:/usr/local/trunk# /usr/local/sbin/opensips
Listening on
             udp: 10.6.2.246 [10.6.2.246]:5060
Aliases:
             udp: stinbng46:5060

stinbng46:/usr/local/trunk# Feb 24 11:46:35 [2520]
ERROR:core:db_check_table_version: invalid version 0 for table
rls_presentity found, expected 1
Feb 24 11:46:35 [2520] ERROR:rls:mod_init: error during table version
check.
Feb 24 11:46:35 [2520] ERROR:core:init_mod: failed to initialize module
rls
Feb 24 11:46:35 [2520] ERROR:core:main: error while initializing modules
i have   rls_presentity table also in opensips database.
mysql> desc rls_presentity
    -> ;
+----------------+------------------+------+-----+---------+----------------+
| Field          | Type             | Null | Key | Default | Extra        
 |
+----------------+------------------+------+-----+---------+----------------+
| id             | int(10) unsigned | NO   | PRI | NULL    |
auto_increment |
| rlsubs_did     | char(255)        | NO   | MUL |         |              
 |
| resource_uri   | char(128)        | NO   |     |         |              
 |
| content_type   | char(64)         | NO   |     |         |              
 |
| presence_state | blob             | NO   |     |         |              
 |
| expires        | int(11)          | NO   |     |         |              
 |
| updated        | int(11)          | NO   | MUL |         |              
 |
| auth_state     | int(11)          | NO   |     |         |              
 |
| reason         | char(64)         | NO   |     |         |              
 |
+----------------+------------------+------+-----+---------+----------------+
9 rows in set (0.00 sec)

I have changed and tried table version in script also 
INSERT INTO version (table_name, table_version) values
('rls_presentity','1');
  CREATE TABLE rls_presentity (
      id INT(10) UNSIGNED AUTO_INCREMENT PRIMARY KEY NOT NULL,
      rlsubs_did CHAR(255) NOT NULL,
      resource_uri CHAR(128) NOT NULL,
      content_type CHAR(64) NOT NULL,
      presence_state BLOB NOT NULL,
      expires INT(11) NOT NULL,
      updated INT(11) NOT NULL,
      auth_state INT(11) NOT NULL,
      reason CHAR(64) NOT NULL,
      CONSTRAINT rls_presentity_idx UNIQUE (rlsubs_did, resource_uri)
  ) ENGINE=MyISAM;
Again i got the same error.

Regards
rmnathan

----------------------------------------------------------------------

Comment By: Anca Vamanu (anca_vamanu)
Date: 2009-02-18 20:47

Message:
Hi Rmnathan,

Thank you for this report.
Indeed, you were right- not all update Notifies were sent due to a bug in
the code. I have fixed it. Please update to the new svn version and test it
yourself. I will wait for your feedback before closing this bug report.

regards,
Anca



----------------------------------------------------------------------

Comment By: Anca Vamanu (anca_vamanu)
Date: 2009-02-18 20:47

Message:
Hi Rmnathan,

Thank you for this report.
Indeed, you were right- not all update Notifies were sent due to a bug in
the code. I have fixed it. Please update to the new svn version and test it
yourself. I will wait for your feedback before closing this bug report.

regards,
Anca



----------------------------------------------------------------------

Comment By: Anca Vamanu (anca_vamanu)
Date: 2009-02-18 20:46

Message:
Hi Rmnathan,

Thank you for this report.
Indeed, you were right- not all update Notifies were sent due to a bug in
the code. I have fixed it. Please update to the new svn version and test it
yourself. I will wait for your feedback before closing this bug report.

regards,
Anca



----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=2591935&group_id=232389


From noreply at sourceforge.net  Tue Feb 24 15:36:35 2009
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 24 Feb 2009 14:36:35 +0000
Subject: [OpenSIPS-Devel] [ opensips-Bugs-2627561 ] auth_radius: allow
	sip-avps to be passed for rejected reques
Message-ID: <E1LbyOh-0008BP-Bp@155xhf1.ch3.sourceforge.com>

Bugs item #2627561, was opened at 2009-02-22 14:09
Message generated for change (Comment added) made by bogdan_iancu
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=2627561&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: Accepted
Priority: 5
Private: No
Submitted By: Alex Massover (cupotka2008)
>Assigned to: Bogdan-Andrei Iancu (bogdan_iancu)
Summary: auth_radius: allow sip-avps to be passed for rejected reques

Initial Comment:
Hi!

This simple patch for auth_radius module allows to pass additional credentials (sip-avps) also for rejected radius requests. For example it can be used for passing custom error codes.

Best Regards,
Alex Massover.

----------------------------------------------------------------------

>Comment By: Bogdan-Andrei Iancu (bogdan_iancu)
Date: 2009-02-24 16:36

Message:
Hi Alex,

Thanks - this is more like a bug, so I moved it accordingly. I will
shortly overview and commit it.

Regards,
Bogdan

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=2627561&group_id=232389


From noreply at sourceforge.net  Tue Feb 24 15:39:42 2009
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 24 Feb 2009 14:39:42 +0000
Subject: [OpenSIPS-Devel] [ opensips-Bugs-2633350 ] Crash in dialog
	module+patch
Message-ID: <E1LbyRi-0004a0-4n@b55xhf1.ch3.sourceforge.com>

Bugs item #2633350, was opened at 2009-02-24 14: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=2633350&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: Accepted
>Priority: 9
Private: No
Submitted By: Vasil Kolev (krokodilerian)
>Assigned to: Bogdan-Andrei Iancu (bogdan_iancu)
Summary: Crash in dialog module+patch

Initial Comment:
When using the dialog module with realtime db usage, it crashes with the following backtrace:

(gdb) bt
#0  0xb77f9104 in update_dialog_dbinfo (cell=0xb57ba410) at dlg_db_handler.c:511
#1  0xb7800370 in dlg_onreply (t=0xb57b0db8, type=128, param=0xb78c1b34) at dlg_handlers.c:323
#2  0xb789d22b in run_trans_callbacks (type=128, trans=0xb57b0db8, req=0xb57bb6f0, rpl=0xffffffff, code=200) at t_hooks.c:208
#3  0xb78b2cf3 in _reply_light (trans=0xb57b0db8, 
    buf=0x819f428 "SIP/2.0 200 OK\r\nVia: SIP/2.0/UDP 89.253.129.130:27819;branch=z9hG4bK-d8754z-cb4ec1c38ba46444-1---d8754z-;rport=27819\r\nTo: <sip:vasil.kolev%40securax.org at sip.zoiper.com;transport=UDP>;tag=945b7285134e5"..., len=<value optimized out>, code=200, to_tag=0xb78d2a40 "945b7285134e5709ca8a0d8ffb065070-ab6d", to_tag_len=37, lock=1, bm=0xbfd0106c) at t_reply.c:373
#4  0xb78b3425 in _reply (trans=0xb57b0db8, p_msg=<value optimized out>, code=200, text=0xb77a4b08, lock=1) at t_reply.c:446
#5  0xb78a75ba in w_t_reply (msg=0x819dfb0, str1=0xc8 <Address 0xc8 out of bounds>, str2=0xb77a4b08 ">\az?\002") at tm.c:863
#6  0xb7d5beba in sig_send_reply_mod (msg=0x819dfb0, code=200, reason=0xb77a4b08, to_tag=0xbfd012f8) at signaling.c:178
#7  0xb779708a in send_2XX_reply (msg=0x819dfb0, reply_code=200, lexpire=<value optimized out>, rtag=0xbfd012f8, local_contact=0xbfd01324) at subscribe.c:112
#8  0xb7797d72 in update_subscription (msg=0x819dfb0, subs=0xbfd012c4, init_req=1) at subscribe.c:378
#9  0xb779c72b in handle_subscribe (msg=0x819dfb0, str1=0x0, str2=0x0) at subscribe.c:699
#10 0x08055591 in do_action (a=0x8196618, msg=0x819dfb0) at action.c:961
#11 0x080541e2 in run_action_list (a=0x8196618, msg=0x819dfb0) at action.c:139
#12 0x08056ecd in do_action (a=0x8197550, msg=0x819dfb0) at action.c:705
#13 0x080541e2 in run_action_list (a=0x8197550, msg=0x819dfb0) at action.c:139
#14 0x08057529 in do_action (a=0x81975b8, msg=0x819dfb0) at action.c:711
#15 0x080541e2 in run_action_list (a=0x81960a8, msg=0x819dfb0) at action.c:139
#16 0x08056914 in do_action (a=0x81934e0, msg=0x819dfb0) at action.c:119
#17 0x080541e2 in run_action_list (a=0x81934e0, msg=0x819dfb0) at action.c:139
#18 0x08056ecd in do_action (a=0x8193548, msg=0x819dfb0) at action.c:705
#19 0x080541e2 in run_action_list (a=0x818e390, msg=0x819dfb0) at action.c:139
#20 0x08057ee1 in run_top_route (a=0x818e390, msg=0x819dfb0) at action.c:119
#21 0x0809228c in receive_msg (
    buf=0x8164220 "SUBSCRIBE sip:vasil.kolev%40securax.org at sip.zoiper.com;transport=UDP SIP/2.0\r\nVia: SIP/2.0/UDP 89.253.129.130:27819;branch=z9hG4bK-d8754z-cb4ec1c38ba46444-1---d8754z-;rport\r\nMax-Forwards: 69\r\nContact:"..., len=933, rcv_info=0xbfd020a4) at receive.c:165
#22 0x080cdf4b in udp_rcv_loop () at udp_server.c:449
#23 0x0806c3af in main (argc=1, argv=0xbfd02234) at main.c:778


When investigating it, turned out that cell->bind_addr[DLG_CALLEE_LEG] is NULL, and while trying to dereference that to get the sock_str, it crashes. I added a check and a specific str null_element to update it right.

Also, there was a strange typo in the LM_DBG there, it was using the value from the cell->bind_addr[DLG_CALLEE_LEG]->sock_str, but the length from cell->bind_addr[DLG_CALLER_LEG]->sock_str.

Patch attached (against trunk).

----------------------------------------------------------------------

>Comment By: Bogdan-Andrei Iancu (bogdan_iancu)
Date: 2009-02-24 16:39

Message:
Hi Vasil,

it seams like a bug - I will review the patch and apply it asap.

Thanks and regards,
Bogdan

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=2633350&group_id=232389


From noreply at sourceforge.net  Tue Feb 24 15:40:58 2009
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 24 Feb 2009 14:40:58 +0000
Subject: [OpenSIPS-Devel] [ opensips-Bugs-2609050 ] Segmentation fault in
	presence module related to MySQL
Message-ID: <E1LbySw-0007Lt-C4@1bkjzd1.ch3.sourceforge.com>

Bugs item #2609050, was opened at 2009-02-17 14: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=2609050&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: Duplicate
Priority: 5
Private: No
Submitted By: I?aki Baz (ibc_sf)
Assigned to: Nobody/Anonymous (nobody)
Summary: Segmentation fault in presence module related to MySQL

Initial Comment:
After upgrading to OpenSIPS rev 5320 a server acting as presence server crashes very often.
There is no traffic at all, just 4 users so very log presence traffic.


syslog:
----------
Feb 17 11:41:26 presence_server /usr/sbin/opensips_presence[7205]: DBG:presence:search_event: start event= [dialog]
Feb 17 11:41:26 presence_server /usr/sbin/opensips_presence[7205]: DBG:presence:handle_publish: SIP-If-Match header found
Feb 17 11:41:26 presence_server /usr/sbin/opensips_presence[7205]: DBG:presence:handle_publish: existing etag  = a.1234829890.9781.1.1
Feb 17 11:41:26 presence_server /usr/sbin/opensips_presence[7205]: DBG:presence:handle_publish: Expires header found, value= 8484
Feb 17 11:41:26 presence_server /usr/sbin/opensips_presence[7205]: DBG:db_mysql:db_mysql_do_prepared_query: new query=|select body,sender from presentity where domain=? AND username=? AND
event=? AND etag=?|
Feb 17 11:41:26 presence_server /usr/sbin/opensips_presence[7205]: DBG:db_mysql:db_mysql_do_prepared_query: prepared statement successfully set...
Feb 17 11:41:26 presence_server /usr/sbin/opensips_presence[7205]: DBG:db_mysql:db_mysql_do_prepared_query: set values for the statement run
Feb 17 11:41:26 presence_server /usr/sbin/opensips_presence[7205]: DBG:db_mysql:db_mysql_val2bind: added val (0): len=9; type=254; is_null=0
Feb 17 11:41:26 presence_server /usr/sbin/opensips_presence[7205]: DBG:db_mysql:db_mysql_val2bind: added val (1): len=3; type=254; is_null=0
Feb 17 11:41:26 presence_server /usr/sbin/opensips_presence[7205]: DBG:db_mysql:db_mysql_val2bind: added val (2): len=6; type=254; is_null=0
Feb 17 11:41:26 presence_server /usr/sbin/opensips_presence[7205]: DBG:db_mysql:db_mysql_val2bind: added val (3): len=21; type=254; is_null=0
Feb 17 11:41:26 presence_server /usr/sbin/opensips_presence[7205]: DBG:db_mysql:db_mysql_do_prepared_query: doing BIND_PARAM in...
Feb 17 11:41:26 presence_server /usr/sbin/opensips_presence[7204]: DBG:db_mysql:db_mysql_do_prepared_query: prepared statement successfully set...
Feb 17 11:41:26 presence_server /usr/sbin/opensips_presence[7204]: DBG:db_mysql:db_mysql_do_prepared_query: set values for the statement run
Feb 17 11:41:26 presence_server /usr/sbin/opensips_presence[7204]: DBG:db_mysql:db_mysql_val2bind: added val (0): len=21; type=254; is_null=0
Feb 17 11:41:26 presence_server /usr/sbin/opensips_presence[7204]: DBG:db_mysql:db_mysql_val2bind: added val (1): len=4; type=3; is_null=0
Feb 17 11:41:26 presence_server /usr/sbin/opensips_presence[7204]: DBG:db_mysql:db_mysql_val2bind: added val (2): len=4; type=3; is_null=0
Feb 17 11:41:26 presence_server /usr/sbin/opensips_presence[7204]: DBG:db_mysql:db_mysql_val2bind: added val (3): len=0; type=254; is_null=0
Feb 17 11:41:26 presence_server /usr/sbin/opensips_presence[7204]: DBG:db_mysql:db_mysql_val2bind: added val (4): len=9; type=254; is_null=0
Feb 17 11:41:26 presence_server /usr/sbin/opensips_presence[7204]: DBG:db_mysql:db_mysql_val2bind: added val (5): len=3; type=254; is_null=0
Feb 17 11:41:26 presence_server /usr/sbin/opensips_presence[7204]: DBG:db_mysql:db_mysql_val2bind: added val (6): len=6; type=254; is_null=0
Feb 17 11:41:26 presence_server /usr/sbin/opensips_presence[7204]: DBG:db_mysql:db_mysql_val2bind: added val (7): len=21; type=254; is_null=0
Feb 17 11:41:26 presence_server /usr/sbin/opensips_presence[7204]: DBG:db_mysql:db_mysql_do_prepared_query: doing BIND_PARAM in...
Feb 17 11:41:26 presence_server /usr/sbin/opensips_presence[7222]: CRITICAL:core:receive_fd: EOF on 9
----------------


coredump:
----------------
#0  0x00002ae413496588 in mysql_stmt_prepare () from /usr/lib/libmysqlclient.so.15
#1  0x00002ae4134989dc in cli_stmt_execute () from /usr/lib/libmysqlclient.so.15
#2  0x00002ae413498495 in mysql_stmt_execute () from /usr/lib/libmysqlclient.so.15
#3  0x00002ae41332322c in db_mysql_free_result () from /usr/lib/opensips/modules/db_mysql.so
#4  0x00002ae41332453f in db_mysql_update () from /usr/lib/opensips/modules/db_mysql.so
#5  0x00002ae414a31185 in update_presentity () from /usr/lib/opensips/modules/presence.so
#6  0x00002ae414a342d5 in handle_publish () from /usr/lib/opensips/modules/presence.so
#7  0x000000000040f894 in do_action ()
#8  0x000000000040e0f3 in run_action_list ()
#9  0x0000000000411df5 in do_action ()
#10 0x000000000040e0f3 in run_action_list ()
#11 0x000000000041176f in do_action ()
#12 0x000000000040e0f3 in run_action_list ()
#13 0x0000000000411df5 in do_action ()
#14 0x000000000040e0f3 in run_action_list ()
#15 0x000000000041093a in do_action ()
#16 0x000000000040e0f3 in run_action_list ()
#17 0x000000000041176f in do_action ()
#18 0x000000000040e0f3 in run_action_list ()
#19 0x000000000040e480 in run_top_route ()
#20 0x0000000000441b4c in receive_msg ()
#21 0x0000000000472990 in udp_rcv_loop ()
#22 0x0000000000423917 in main ()
----------------

----------------------------------------------------------------------

>Comment By: Bogdan-Andrei Iancu (bogdan_iancu)
Date: 2009-02-24 16:40

Message:
merged with 2608188.

----------------------------------------------------------------------

Comment By: Bogdan-Andrei Iancu (bogdan_iancu)
Date: 2009-02-17 16:11

Message:
Hi,

maybe this is related to bug #2608188 - it a report for prepared
statements crashing when reconnecting to mysql server....maybe it is the
same case here...

Regards,
Bogdan

----------------------------------------------------------------------

Comment By: I?aki Baz (ibc_sf)
Date: 2009-02-17 16:03

Message:
Hi Anca, tested again with rev5323 and a similar error occurs with exactly
the same backtrace.

syslog:
------------
/usr/sbin/opensips_presence[19199]: DBG:core:parse_msg: SIP Request:
/usr/sbin/opensips_presence[19199]: DBG:core:parse_msg:  method: 
<SUBSCRIBE>
/usr/sbin/opensips_presence[19199]: DBG:core:parse_msg:  uri:    
<sip:manwe at d
/usr/sbin/opensips_presence[19199]: DBG:core:parse_msg:  version:
<SIP/2.0>
/usr/sbin/opensips_presence[19199]: DBG:core:parse_headers: flags=2
/usr/sbin/opensips_presence[19199]: DBG:core:parse_via_param: found param
type
/usr/sbin/opensips_presence[19199]: DBG:core:parse_via: end of header
reached,
/usr/sbin/opensips_presence[19199]: DBG:core:parse_headers: via found,
flags=2
/usr/sbin/opensips_presence[19199]: DBG:core:parse_headers: this is the
first 
/usr/sbin/opensips_presence[19199]: DBG:core:receive_msg: After
parse_msg...
/usr/sbin/opensips_presence[19199]: DBG:core:receive_msg: preparing to run
rou
/usr/sbin/opensips_presence[19199]: DBG:core:parse_headers: flags=100
/usr/sbin/opensips_presence[19199]: DBG:core:parse_via_param: found param
type
/usr/sbin/opensips_presence[19199]: DBG:core:parse_via_param: found param
type
/usr/sbin/opensips_presence[19199]: DBG:core:parse_via_param: found param
type
/usr/sbin/opensips_presence[19199]: DBG:core:parse_via: end of header
reached,
/usr/sbin/opensips_presence[19199]: DBG:core:parse_headers: via found,
flags=1
/usr/sbin/opensips_presence[19199]: DBG:core:parse_headers: parse_headers:
thi
/usr/sbin/opensips_presence[19199]: DBG:maxfwd:is_maxfwd_present: value =
69
/usr/sbin/opensips_presence[19199]: DBG:core:parse_headers: flags=78
/usr/sbin/opensips_presence[19199]: DBG:core:parse_to: end of header
reached, 
/usr/sbin/opensips_presence[19199]: DBG:core:parse_to: display={},
ruri={sip:m
/usr/sbin/opensips_presence[19199]: DBG:core:get_hdr_field: <To> [23];
uri=[si
/usr/sbin/opensips_presence[19199]: DBG:core:get_hdr_field: to body
[<sip:manw
/usr/sbin/opensips_presence[19199]: DBG:core:get_hdr_field: cseq <CSeq>:
<410>
/usr/sbin/opensips_presence[19199]: DBG:tm:t_lookup_request: start
searching: 
/usr/sbin/opensips_presence[19199]: DBG:tm:matching_3261: RFC3261
transaction 
/usr/sbin/opensips_presence[19199]: DBG:tm:t_lookup_request: no
transaction fo
/usr/sbin/opensips_presence[19199]:
/usr/sbin/opensips_presence[19199]: DBG:uri:has_totag: no totag
/usr/sbin/opensips_presence[19199]: DBG:core:tr_eval_string: i=11 j=8
/usr/sbin/opensips_presence[19199]: DBG:core:parse_headers: flags=8000000
/usr/sbin/opensips_presence[19199]: 14:56:12 - request from
92.122.79.216:3689
/usr/sbin/opensips_presence[19199]: SUBSCRIBE sip:manwe at domain.net
/usr/sbin/opensips_presence[19199]: DBG:core:parse_to_param: tag=doohb
/usr/sbin/opensips_presence[19199]: DBG:core:parse_to: end of header
reached, 
/usr/sbin/opensips_presence[19199]: DBG:core:parse_to: display={"I?aki"},
ruri
/usr/sbin/opensips_presence[19199]: From: "I?aki" <sip:ibc at domain.net>
/usr/sbin/opensips_presence[19199]: DBG:core:pv_get_xto_attr: no Display
name
/usr/sbin/opensips_presence[19199]: To:   <null> <sip:manwe at domain.net>
/usr/sbin/opensips_presence[19199]: DBG:core:parse_headers:
flags=ffffffffffff
/usr/sbin/opensips_presence[19199]: DBG:core:get_hdr_field:
content_length=0
/usr/sbin/opensips_presence[19199]: DBG:core:get_hdr_field: found end of
heade
/usr/sbin/opensips_presence[19199]: DBG:presence:search_event: start
event= [p
/usr/sbin/opensips_presence[19199]: DBG:presence:extract_sdialog_info:
'Expire
/usr/sbin/opensips_presence[19199]: DBG:presence:extract_sdialog_info:
'To' he
/usr/sbin/opensips_presence[19199]: DBG:presence:extract_sdialog_info:
initial
/usr/sbin/opensips_presence[19199]: DBG:presence:extract_sdialog_info:
subs->c
/usr/sbin/opensips_presence[19199]: DBG:core:print_rr_body: current rr is
<sip
/usr/sbin/opensips_presence[19199]: DBG:core:print_rr_body: current rr is
<sip
/usr/sbin/opensips_presence[19199]: DBG:core:print_rr_body: out rr
[<sip:92.12
/usr/sbin/opensips_presence[19199]: DBG:core:print_rr_body: we have 2
records
/usr/sbin/opensips_presence[19199]:
DBG:db_mysql:db_mysql_do_prepared_query: s
/usr/sbin/opensips_presence[19199]: DBG:db_mysql:db_mysql_val2bind: added
val 
/usr/sbin/opensips_presence[19199]: DBG:db_mysql:db_mysql_val2bind: added
val 
/usr/sbin/opensips_presence[19199]: DBG:db_mysql:db_mysql_val2bind: added
val 
/usr/sbin/opensips_presence[19199]: DBG:db_mysql:db_mysql_val2bind: added
val 
/usr/sbin/opensips_presence[19199]:
DBG:db_mysql:db_mysql_do_prepared_query: d
/usr/sbin/opensips_presence[19207]: DBG:core:handle_tcp_child: dead tcp
child 
/usr/sbin/opensips_presence[19207]: DBG:core:io_watch_del: io_watch_del
(0x5fe
/usr/sbin/opensips_presence[19207]: CRITICAL:core:receive_fd: EOF on 21
/usr/sbin/opensips_presence[19207]: DBG:core:handle_ser_child: dead child
11, 
/usr/sbin/opensips_presence[19207]: DBG:core:io_watch_del: io_watch_del
(0x5fe
/usr/sbin/opensips_presence[19188]: INFO:core:handle_sigs: child process
19199
/usr/sbin/opensips_presence[19188]: INFO:core:handle_sigs: core was
generated
/usr/sbin/opensips_presence[19188]: INFO:core:handle_sigs: terminating due
to 
/usr/sbin/opensips_presence[19207]: INFO:core:sig_usr: signal 15 received
------------


Note however that I'm testing presence_dialoginfo module. I will dissable
it now and try again.

PD: There is an ERROR in the logs:

---------
ERROR:db_mysql:db_mysql_do_prepared_query: mysql_stmt_execute() failed:
Lost connection to MySQL server during query
Feb 17 15:02:42 presence_server /usr/sbin/opensips_presence[20031]:
ERROR:presence:update_presentity: inserting new record in database
---------

----------------------------------------------------------------------

Comment By: Anca Vamanu (anca_vamanu)
Date: 2009-02-17 15:00

Message:
Hi Inaki,

I also noticed that there are problems with prepare statements and
operations in presentity table. But I thought that they occur only when
querying, because prepare statements put the result in a static buffer.
Just a couple of minutes ago I took out using prepare statements with
queries. 

From noreply at sourceforge.net  Tue Feb 24 15:44:20 2009
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 24 Feb 2009 14:44:20 +0000
Subject: [OpenSIPS-Devel] [ opensips-Bugs-2538399 ] Bug in presence when
	using fallback2db
Message-ID: <E1LbyWC-0000fV-Mi@565xhf1.ch3.sourceforge.com>

Bugs item #2538399, was opened at 2009-01-26 14:39
Message generated for change (Comment added) made by oren_k
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=2538399&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: Oren K (oren_k)
Assigned to: Anca Vamanu (anca_vamanu)
Summary: Bug in presence when using fallback2db

Initial Comment:
Hi,

While using the presence module, I run this scenario:

a. user1 SUBSCRIBE's to presence of user2
(subscription is now pending)

b. user2 allows user1 in pres-rules
(refreshWatchers is called, subscription is now active. user1 receives a NOTIFY from presence server with user2's current tuple and Subscription-State: active)

c. user2 PUBLISH'es a new presence tuple
-- at this point presence server should NOTIFY user1 of the new presence but it doesn't (that's the bug).


My modparams:

modparam("presence|presence_xml", "db_url", "mysql://root at localhost/opensips")

modparam("presence", "server_address", "sip:presence.example.com:10500")

modparam("presence", "fallback2db", 1)
modparam("presence", "clean_period", 30)


What I see in the debug trace is that get_subs_dialog (from notify.c) can't find any dialogs in the database, and all those in the subs hash are flagged NO_UPDATEDB_FLAG. This is probably what's causing the problem. 
Strangely, in the above scenario if user1 un-SUBSCRIBEs and re-SUBSCRIBEs to user2's presence - it does receive notifications.

Regards,
Oren K.

----------------------------------------------------------------------

>Comment By: Oren K (oren_k)
Date: 2009-02-24 09:44

Message:
It would appear that OpenSIPS does not reply in a timely manner:

Feb 23 12:34:58 openims /usr/local/sbin/opensips[3091]:
DBG:tm:utimer_routine: timer routine:4,tl=0xb6183d1c next=(nil),
timeout=974500000
Feb 23 12:35:01 openims opensips-mi-proxy[2368]: [-] error: Error while
processing command refreshWatchers (sip:user2 at openims.summit-tech.ca
presence 0): OpenSIP
S command did timeout

Strangely the first mi_refresh_watchers gets through, this exception only
happens in the second time its called. I'm attaching the logfile from this
run so you can have a look. OpenSIPS does not report any errors, but the
scenario still happens: No NOTIFY is received after user2 PUBLISHes.

----------------------------------------------------------------------

Comment By: Anca Vamanu (anca_vamanu)
Date: 2009-02-24 04:41

Message:
Hi, 

It does not help me if you say what error you get in opensips-mi-proxy. It
would have been better if you said what is the error in opensips :) .
Please look in the log, find the error and print it here.

regards, 
Anca

----------------------------------------------------------------------

Comment By: Oren K (oren_k)
Date: 2009-02-23 12:38

Message:
Thanks for your help Anca. I updated my sources from SVN and recompiled but
unfortunately the bug is still not resolved. I am still getting a crash
from opensips-mi-proxy, its the same one as on my previous comment from
Date: 2009-02-20 13:22

exceptions.ValueError: invalid literal for int() with base 10: 'OpenSIPS'

----------------------------------------------------------------------

Comment By: Anca Vamanu (anca_vamanu)
Date: 2009-02-23 08:57

Message:
Hi Oren,

I have fixed the problem with 'transformations' node. Please update and
test again.

Thanks,
Anca

----------------------------------------------------------------------

Comment By: Oren K (oren_k)
Date: 2009-02-20 13:53

Message:
also I was getting errors because I didn't have a transformations node. The
common-policy schema states that transformations isn't a must-have, and I
think opensips should treat no transformations node the same as if there
was an empty one.

<xs:element name="transformations" type="cp:extensibleType"
minOccurs="0"/>

However, adding a <transformations/> to my pres-rules had not effect on
this bug (still happens).

----------------------------------------------------------------------

Comment By: Oren K (oren_k)
Date: 2009-02-20 13:22

Message:
Something else is wrong now. mi_refresh_watchers is getting a timeout. This
didn't happen before. I'm using:
OpenXCAP 1.0.6
opensips-mi-proxy 1.0.2

Right now nothing works, not even normal scenarios.

Feb 20 13:16:22 openims opensips-mi-proxy[2368]: [-] error: Error while
processing command refreshWatchers (sip:user2 at openims.summit-tech.ca
presence 0): O
penSIPS command did timeout
Feb 20 13:16:22 openims opensips-mi-proxy[2368]: [-] Exception rendering:
Feb 20 13:16:22 openims opensips-mi-proxy[2368]: [-] Traceback (most
recent call last):
Feb 20 13:16:22 openims opensips-mi-proxy[2368]: [-]       File
"/usr/lib/python2.5/site-packages/Twisted-8.2.0_r25964-py2.5-linux-i686.egg/twisted/interne
t/defer.py", line 312, in _startRunCallbacks
Feb 20 13:16:22 openims opensips-mi-proxy[2368]: [-]        
self._runCallbacks()
Feb 20 13:16:22 openims opensips-mi-proxy[2368]: [-]       File
"/usr/lib/python2.5/site-packages/Twisted-8.2.0_r25964-py2.5-linux-i686.egg/twisted/interne
t/defer.py", line 328, in _runCallbacks
Feb 20 13:16:22 openims opensips-mi-proxy[2368]: [-]         self.result =
callback(self.result, *args, **kw)
Feb 20 13:16:22 openims opensips-mi-proxy[2368]: [-]       File
"/usr/lib/python2.5/site-packages/Twisted-8.2.0_r25964-py2.5-linux-i686.egg/twisted/interne
t/defer.py", line 289, in _continue
Feb 20 13:16:22 openims opensips-mi-proxy[2368]: [-]        
self.unpause()
Feb 20 13:16:22 openims opensips-mi-proxy[2368]: [-]       File
"/usr/lib/python2.5/site-packages/Twisted-8.2.0_r25964-py2.5-linux-i686.egg/twisted/interne
t/defer.py", line 285, in unpause
Feb 20 13:16:22 openims opensips-mi-proxy[2368]: [-]        
self._runCallbacks()
Feb 20 13:16:22 openims opensips-mi-proxy[2368]: [-]     --- <exception
caught here> ---
Feb 20 13:16:22 openims opensips-mi-proxy[2368]: [-]       File
"/usr/lib/python2.5/site-packages/Twisted-8.2.0_r25964-py2.5-linux-i686.egg/twisted/interne
t/defer.py", line 328, in _runCallbacks
Feb 20 13:16:22 openims opensips-mi-proxy[2368]: [-]         self.result =
callback(self.result, *args, **kw)
Feb 20 13:16:22 openims opensips-mi-proxy[2368]: [-]       File
"/usr/lib/python2.5/site-packages/miproxy/proxy.py", line 89, in _cbRender
Feb 20 13:16:22 openims opensips-mi-proxy[2368]: [-]         code =
int(code)
Feb 20 13:16:22 openims opensips-mi-proxy[2368]: [-]    
exceptions.ValueError: invalid literal for int() with base 10: 'OpenSIPS'


----------------------------------------------------------------------

Comment By: Anca Vamanu (anca_vamanu)
Date: 2009-02-20 07:59

Message:
Hi,

I have just made a fix. Please update, test again and reply.

Thanks,
Anca

----------------------------------------------------------------------

Comment By: Anca Vamanu (anca_vamanu)
Date: 2009-02-20 07:25

Message:
Hi Oren,

I have looked into the log file that you posted and saw that there was and
error there. There is a problem with the body of the Publish message -
which causes stopping the processing. The problem is that the code in the
presence server expects a tuple element in the body - and the body of the
last Publish message does not contain one.
I have looked up in the RFC and saw that the tuple element is in fact not
compulsory - so there is a bug in the presence code - but not the one you
reported :). 
I will fix this soon.

Thanks and regards,
Anca

----------------------------------------------------------------------

Comment By: Oren K (oren_k)
Date: 2009-02-19 18:42

Message:
Still no joy.. adding updated log and pcap for the version i compiled from
svn 1.5.0dev5-tls.

----------------------------------------------------------------------

Comment By: Anca Vamanu (anca_vamanu)
Date: 2009-02-18 11:11

Message:
Hi, 

I have just now made some changes in presence module for fallback2db case.
Can you please update to the newest svn version for 1.5 and test again?

regards,
Anca

----------------------------------------------------------------------

Comment By: Anca Vamanu (anca_vamanu)
Date: 2009-02-18 11:10

Message:
Hi, 

I have just now made some changes in presence module for fallback2db case.
Can you please update to the newest svn version for 1.5 and test again?

regards,
Anca

----------------------------------------------------------------------

Comment By: Oren K (oren_k)
Date: 2009-02-06 19:23

Message:
Hi Anca,

I've attached a debug-log and wireshark pcap file to the post. The pcap
file also contains the XCAP PUTs to change the presence rules. The only
error in the log comes from presence_xml not being able to extract a tuple
node because our client uses <pdm:person> for the presence (Same bug
happened to us when we tried with <tuple> so that's not the issue). The
things that strike me odd in presence_bug.log are:

(after step b. user2 allows user1 in pres-rules)
line 634: DBG:presence:update_pw_dialogs: found 1 matching dialogs

the module finds the watcher dialog and updates it due to refreshWatchers.
user1 receives a NOTIFY with Subscription-State:active. Now step c. user2
PUBLISH'es a new presence tuple:

line 919: DBG:core:parse_msg:  method:  <PUBLISH>

everything looks okay BUT:

line 1087: DBG:presence:get_subs_db: The query for subscribtion for [uri]=
sip:user2 at openims.summit-tech.ca for [event]= presence returned no result
line 1110: DBG:presence:get_subs_dialog: s->db_flag== UPDATEDB_FLAG
line 1111: DBG:presence:get_subs_dialog: found 0 dialogs( 0 in database
and 0 in hash_table)
line 1112: DBG:presence:publ_notify: Could not find subs_dialog

..suddenly there are no subscribers?

Thanks.


----------------------------------------------------------------------

Comment By: Anca Vamanu (anca_vamanu)
Date: 2009-02-06 13:14

Message:
Hi Oren,

I have just downloaded myself the release and tested and the scenario that
you described works. 
Do you notice any error in your log file?

regards,
Anca

----------------------------------------------------------------------

Comment By: Oren K (oren_k)
Date: 2009-02-01 11:41

Message:
Sorry I forgot to login, that comment is from me :)

----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2009-01-28 10:12

Message:
Thanks for the reply anca. Version is opensips-1.4.4-tls, compiled from the
sources with TLS="1". 

----------------------------------------------------------------------

Comment By: Anca Vamanu (anca_vamanu)
Date: 2009-01-28 06:48

Message:
Hi Oren,

What OpenSIPS version are you using? Trunk or stable release?

regards,
Anca

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=2538399&group_id=232389


From noreply at sourceforge.net  Tue Feb 24 16:19:14 2009
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 24 Feb 2009 15:19:14 +0000
Subject: [OpenSIPS-Devel] [ opensips-Bugs-2591935 ] Error in sending NOTIFY
	for PUBLISH in RLS mode
Message-ID: <E1Lbz3y-0006Bo-OU@d45xhf1.ch3.sourceforge.com>

Bugs item #2591935, was opened at 2009-02-12 12:01
Message generated for change (Comment added) made by rmnathan
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=2591935&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: Nathan (rmnathan)
Assigned to: Anca Vamanu (anca_vamanu)
Summary: Error in sending NOTIFY for PUBLISH in RLS mode

Initial Comment:
Hi
When opensips got publish for the user(say E1_1) which has in two list subscriptions, it is sending notify to one user only.
For example:
UE2_1 list will have 2 entry uri like E1_1,E1_2
UE2_2 list will have 2 entry uri like E1_2,E1_1

S2_1 subscribe to UE2_1
S2_2 subscribe to UE2_2
If E1_1 send publish, opensips sends notify to S2_1 only. But it should send notify to S2_2 too.

Please find the attached pcap file for detailed call flow.

Regards,
rmnathan


----------------------------------------------------------------------

Comment By: Nathan (rmnathan)
Date: 2009-02-24 20:49

Message:
Hi Anca,

For the same setup
Test setup details
IMS UE1 192.168.165.151:5070
IMS UE2 192.168.165.152:5075
Proxy - SCSCF (192.168.166.150:50602)
Opensips(presence server) (10.6.2.246:5060)
RLS (10.6.2.246:5060)

The difference is two users in the IMS UE1 users list

IMS UE1 has two users
1.c3-1 which has s3-1 in list

<?xml version="1.0" encoding="UTF-8"?>
 <rls-services>
 <service uri="sip:c3-1_list at 10.6.2.246">
   <list name="c3-1">
    <entry uri="sip:s3-1 at 10.6.2.246"/>
    <entry uri="sip:s3-2 at 10.6.2.246"/>
   </list>
   <packages>
    <package>presence</package>
   </packages>
  </service>


2.c3-2 which has also s3-1 in list

<?xml version="1.0" encoding="UTF-8"?>
 <rls-services>
 <service uri="sip:c3-2_list at 10.6.2.246">
   <list name="c3-2">
    <entry uri="sip:s3-1 at 10.6.2.246"/>
    <entry uri="sip:s3-2 at 10.6.2.246"/>
   </list>
   <packages>
    <package>presence</package>
   </packages>
  </service>
 </rls-services>


IMS UE2 has one user
1.s3-1 ( this is only to send publish)
2.s3-2 (this is only to send publish)

call flow description
=====================
1.IMS UE1 ie(c3-1 and c3-2) will send subcribe to their list
2. Presence server that receives the Subscribe messages sent by the rls
server for the list subscription because the users
  in the list are same domain of presence server. So RLS server sends
subscribe, 200 ok for subscribe , Notify and 200 ok
  for notify to presence server(ie to itself because opensips and RLS
server running on same IP: 10.6.2.246)
3. After got 200 ok for subscribe and notify  for IMS UE1 users
4. Send subscribe from IMS UE2 (ie s3-1 to c3-1 & s3-2 to c3-2) . This is
just to send publish.
5. Then send publish from s3-1 and s3-2  ie from IMS UE2.
6. After got publish RLS server should generate notify to c3-1 and c3-2
because c3-1 & c3-2 have subscribed to s3-1 and s3-2
7. From captured trace RLS server sends notify and 200 ok for notify to
presence server 
Analysis
=========
8. Then after that RLS sends notify to IMS UE1
    i) from s3-1 to c3-1
    ii) from s3-2 to c3-2
    iii) from s3-1 to c3-1 this is not correct. it should send from s3-1
to c3-2
    iV) from s3-2 to c3-2 this is not correct. it should send from s3-2 to
c3-1

Please find captured trace also.

Regards
rmnathan

----------------------------------------------------------------------

Comment By: Nathan (rmnathan)
Date: 2009-02-24 19:14

Message:
Hi,
Test setup details
IMS UE1 192.168.165.151:5070
IMS UE2  192.168.165.152:5075
Proxy - SCSCF (192.168.166.150:50602)
Opensips(presence server) (10.6.2.246:5060) 
RLS (10.6.2.246:5060)



----------------------------------------------------------------------

Comment By: Nathan (rmnathan)
Date: 2009-02-24 19:07

Message:
Hi Anca

Test setup description:
======================

IMS UE1
192.168.165.151:5070
				Proxy - SCSCF            ----  Opensips(presence server)   ---- RLS
server
			  (192.168.166.150:50602)	       (10.6.2.246:5060)               
(10.6.2.246:5060)
IMS UE2
192.168.165.152:5075


IMS UE1 has two users 
1.c3-1 which has s3-1 in list

<?xml version="1.0" encoding="UTF-8"?>
 <rls-services>
 <service uri="sip:c3-1_list at 10.6.2.246">
   <list name="c3-1">
    <entry uri="sip:s3-1 at 10.6.2.246"/>

   </list>
   <packages>
    <package>presence</package>
   </packages>
  </service>
 </rls-services>

2.c3-2 which has also s3-1 in list

<?xml version="1.0" encoding="UTF-8"?>
 <rls-services>
 <service uri="sip:c3-2_list at 10.6.2.246">
   <list name="c3-2">
    <entry uri="sip:s3-1 at 10.6.2.246"/>

   </list>
   <packages>
    <package>presence</package>
   </packages>
  </service>
 </rls-services>

IMS UE2 has one user
1.s3-1 ( this is only to send publish)


call flow description
=====================
1.IMS UE1 ie(c3-1 and c3-2) will send subcribe to their list
2. Presence server that receives the Subscribe messages sent by the rls
server for the list subscription because the users
  in the list are same domain of presence server. So RLS server sends
subscribe, 200 ok for subscribe , Notify and 200 ok
  for notify to presence server(ie to itself because opensips and RLS
server running on same IP: 10.6.2.246)
3. After got 200 ok for subscribe and notify  for IMS UE1 users
4. Send subscribe from IMS UE2 (ie s3-1 to c3-1) . This is just to send
publish.
5. Then send publish from s3-1 ie from IMS UE2. 
6. After got publish RLS server should generate notify to c3-1 and c3-2
because c3-1 & c3-2 have subscribed to s3-1 
7. From captured trace RLS server sends notify and 200 ok for notify to
presence server (please explain why this is sending notify to opensips)
8. Then after that RLS sends notify to IMS UE1

9. refreshed Publish from IMS UE2
10 Removed Publish  from IMS UE2


For your queries
================
do you use a presence server that receives the
Subscribe messages sent by the rls server and also Publish messages from
the clients?

yes presence server receives the subscribe messages sent by the rls
server. The publish from clients (in this case from s3-1 (IMS UE2)

2.you send the Subscribes directly to the clients and they
reply with Notifies?
No. the subscribes sends to presence server by the rls server.

Please let me know if you want more information.
Please find captured trace also.

Regards
rmnathan


----------------------------------------------------------------------

Comment By: Anca Vamanu (anca_vamanu)
Date: 2009-02-24 18:22

Message:
Hi Rmnathan,

If you really want to help me figure out what your problem is you have to
send simpler traces. Your trace is impossible to analize - you have 8 lists
with different names, but there are 4 pairs having the same content - so
there are actually only 4 unique lists. Then you use in 'From' header of
the SUBSCRIBE not the name of the list but anther uri - this is not
important in the SIP logic - but it makes impossible for me to follow the
messages since the Notifies that the RLS sends and receives will have the
same To and From headers.
Please if you want to help run a simpler case - only two Subscriptions to
lists that can have different names but the same content. 
One more question - do you use a presence server that receives the
Subscribe messages sent by the rls server and also Publish messages from
the clients? Or you send the Subscribes directly to the clients and they
reply with Notifies?
Please also include a description with the entities in the scenario and
the IP address and port they run at.

Thanks,
Anca


----------------------------------------------------------------------

Comment By: Anca Vamanu (anca_vamanu)
Date: 2009-02-24 16:59

Message:
Hi Rmnathan,

If you really want to help me figure out what your problem is you have to
send simpler traces. Your trace is impossible to analize - you have 8 lists
with different names, but there are 4 pairs having the same content - so
there are actually only 4 unique lists. Then you use in 'From' header of
the SUBSCRIBE not the name of the list but anther uri - this is not
important in the SIP logic - but it makes impossible for me to follow the
messages since the Notifies that the RLS sends and receives will have the
same To and From headers.
Please if you want to help run a simpler case - only two Subscriptions to
lists that can have different names but the same content. 
One more question - do you use a presence server that receives the
Subscribe messages sent by the rls server and also Publish messages from
the clients? Or you send the Subscribes directly to the clients and they
reply with Notifies?
Please also include a description with the entities in the scenario and
the IP address and port they run at.

Thanks,
Anca


----------------------------------------------------------------------

Comment By: Nathan (rmnathan)
Date: 2009-02-24 16:13

Message:
Hi Anca,
After that i have tested. still the issue is not fixed. Now opensips is
generating notify for all the users(for first user) in the list but it
always sending to first user in the list only not for other users. 

Please see the attached pcap file.

Regards
rmnathan



----------------------------------------------------------------------

Comment By: Anca Vamanu (anca_vamanu)
Date: 2009-02-24 15:19

Message:
Hi Rmnathan,

A change was made for many tables - changing varchar type to char and
since the structure was changed, the version of the tables was increased.
You need to get the new mysql script and recreate the table and also
update the version for rls_presentity table in 'version' table. However
since there are many tables for which the version was increased I would
recommend recreating the whole database.

regards,
Anca

----------------------------------------------------------------------

Comment By: Nathan (rmnathan)
Date: 2009-02-24 11:53

Message:
Hi Anca,
I tried with latest trunk 5354 build. while starting opensips i got
following error message
stinbng46:/usr/local/trunk# /usr/local/sbin/opensips
Listening on
             udp: 10.6.2.246 [10.6.2.246]:5060
Aliases:
             udp: stinbng46:5060

stinbng46:/usr/local/trunk# Feb 24 11:46:35 [2520]
ERROR:core:db_check_table_version: invalid version 0 for table
rls_presentity found, expected 1
Feb 24 11:46:35 [2520] ERROR:rls:mod_init: error during table version
check.
Feb 24 11:46:35 [2520] ERROR:core:init_mod: failed to initialize module
rls
Feb 24 11:46:35 [2520] ERROR:core:main: error while initializing modules
i have   rls_presentity table also in opensips database.
mysql> desc rls_presentity
    -> ;
+----------------+------------------+------+-----+---------+----------------+
| Field          | Type             | Null | Key | Default | Extra        
 |
+----------------+------------------+------+-----+---------+----------------+
| id             | int(10) unsigned | NO   | PRI | NULL    |
auto_increment |
| rlsubs_did     | char(255)        | NO   | MUL |         |              
 |
| resource_uri   | char(128)        | NO   |     |         |              
 |
| content_type   | char(64)         | NO   |     |         |              
 |
| presence_state | blob             | NO   |     |         |              
 |
| expires        | int(11)          | NO   |     |         |              
 |
| updated        | int(11)          | NO   | MUL |         |              
 |
| auth_state     | int(11)          | NO   |     |         |              
 |
| reason         | char(64)         | NO   |     |         |              
 |
+----------------+------------------+------+-----+---------+----------------+
9 rows in set (0.00 sec)

I have changed and tried table version in script also 
INSERT INTO version (table_name, table_version) values
('rls_presentity','1');
  CREATE TABLE rls_presentity (
      id INT(10) UNSIGNED AUTO_INCREMENT PRIMARY KEY NOT NULL,
      rlsubs_did CHAR(255) NOT NULL,
      resource_uri CHAR(128) NOT NULL,
      content_type CHAR(64) NOT NULL,
      presence_state BLOB NOT NULL,
      expires INT(11) NOT NULL,
      updated INT(11) NOT NULL,
      auth_state INT(11) NOT NULL,
      reason CHAR(64) NOT NULL,
      CONSTRAINT rls_presentity_idx UNIQUE (rlsubs_did, resource_uri)
  ) ENGINE=MyISAM;
Again i got the same error.

Regards
rmnathan

----------------------------------------------------------------------

Comment By: Anca Vamanu (anca_vamanu)
Date: 2009-02-18 20:47

Message:
Hi Rmnathan,

Thank you for this report.
Indeed, you were right- not all update Notifies were sent due to a bug in
the code. I have fixed it. Please update to the new svn version and test it
yourself. I will wait for your feedback before closing this bug report.

regards,
Anca



----------------------------------------------------------------------

Comment By: Anca Vamanu (anca_vamanu)
Date: 2009-02-18 20:47

Message:
Hi Rmnathan,

Thank you for this report.
Indeed, you were right- not all update Notifies were sent due to a bug in
the code. I have fixed it. Please update to the new svn version and test it
yourself. I will wait for your feedback before closing this bug report.

regards,
Anca



----------------------------------------------------------------------

Comment By: Anca Vamanu (anca_vamanu)
Date: 2009-02-18 20:46

Message:
Hi Rmnathan,

Thank you for this report.
Indeed, you were right- not all update Notifies were sent due to a bug in
the code. I have fixed it. Please update to the new svn version and test it
yourself. I will wait for your feedback before closing this bug report.

regards,
Anca



----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=2591935&group_id=232389


From bogdan at voice-system.ro  Tue Feb 24 16:56:09 2009
From: bogdan at voice-system.ro (Bogdan-Andrei Iancu)
Date: Tue, 24 Feb 2009 17:56:09 +0200
Subject: [OpenSIPS-Devel] OpenSIPS at Amoocon (former AsteriskTag)
Message-ID: <49A41899.8020401@voice-system.ro>

Hi,

In behalf of OpenSIPS project, I submitted several papers for the 
Amoocon (Former AsteriskTag) on May 4th - 5th, 2009 - See 
http://www.amoocon.de/

Covered topics are : Load-balancing (using the new load-balancer module) 
, Presence (deploy presence) and clustering (OpenSIPS + PBX integration):

(1) Load balancing Workshop:
     http://www.amoocon.de/talks/8

(2) Delivering Presence to end-users:
     http://www.amoocon.de/talks/46

(3) OpenSIPS + Yate integration (unified clustering):
     http://www.amoocon.de/talks/47


So, for who ever participate to the Amoocon, feel free to join.

Regards,
Bogdan


From noreply at sourceforge.net  Tue Feb 24 18:11:15 2009
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 24 Feb 2009 17:11:15 +0000
Subject: [OpenSIPS-Devel] [ opensips-Bugs-2634285 ] Nat_traversal:
	opensipsctl ul rm doesn't clean up keepalives
Message-ID: <E1Lc0oN-0002GB-Ne@155xhf1.ch3.sourceforge.com>

Bugs item #2634285, was opened at 2009-02-24 18:11
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=2634285&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: Thomas Gelf (thomas_gelf)
Assigned to: Nobody/Anonymous (nobody)
Summary: Nat_traversal: opensipsctl ul rm doesn't clean up keepalives

Initial Comment:
Running

> opensipsctl ul rm user at domain.tld

doesn't seem to affect nat_traversal's keep-alive state.

Steps I followed to reproduce this issue:
* removed all registrations
* stopped OpenSIPS
* removed keep-alive state file
* started OpenSIPS
* booted some test device
* let devices (all of them behind NAT) REGISTER themselves
* stopped OpenSIPS, manually compared usrloc entries and keep-alive state file
* everything seemed to be fine
* restarted OpenSIPS, "ul rm" for one user, stopped OpenSIPS
* old entry is still to be found in keep-alive state file

OpenSIPS version: SVN trunk, updated this morning. If you need more tests please let me know!

Best regards,
Thomas Gelf


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=2634285&group_id=232389


From saguti at gmail.com  Wed Feb 25 03:56:23 2009
From: saguti at gmail.com (Sergio Gutierrez)
Date: Wed, 25 Feb 2009 02:56:23 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[5355]
 trunk/modules/closeddial/doc/closeddial_admin. xml
Message-ID: <E1Lc9wd-0003IR-UV@c3vjzd1.ch3.sourceforge.com>

Revision: 5355
          http://opensips.svn.sourceforge.net/opensips/?rev=5355&view=rev
Author:   saguti
Date:     2009-02-25 02:56:23 +0000 (Wed, 25 Feb 2009)

Log Message:
-----------
- Minor fix on example.

Modified Paths:
--------------
    trunk/modules/closeddial/doc/closeddial_admin.xml


This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site.


From saguti at gmail.com  Wed Feb 25 04:07:48 2009
From: saguti at gmail.com (Sergio Gutierrez)
Date: Wed, 25 Feb 2009 03:07:48 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[5356]
	trunk/modules/closeddial/README
Message-ID: <E1LcA7g-0003TK-Cv@c3vjzd1.ch3.sourceforge.com>

Revision: 5356
          http://opensips.svn.sourceforge.net/opensips/?rev=5356&view=rev
Author:   saguti
Date:     2009-02-25 03:07:48 +0000 (Wed, 25 Feb 2009)

Log Message:
-----------
- Minor fix in example.

Modified Paths:
--------------
    trunk/modules/closeddial/README


This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site.


From rod at racequeen.ph  Thu Feb 19 08:41:47 2009
From: rod at racequeen.ph (bay2x1)
Date: Wed, 18 Feb 2009 23:41:47 -0800 (PST)
Subject: [OpenSIPS-Devel]  CDRtool and mediaproxy problem
Message-ID: <1235029307787-2351744.post@n2.nabble.com>


I have manage to install opensips 1.5, CDRTool, and Mediaproxy. It seem that
they are working until I found out that the sessions on relay and dispatcher
are not being recorded,  in other words no accounting of call/s are
generated. I have no idea on what I have misconfigured here. Users can make
and receive calls perfectly. Any idea on this problem would be appreciated
greatly.
-- 
View this message in context: http://n2.nabble.com/CDRtool-and-mediaproxy-problem-tp2351744p2351744.html
Sent from the OpenSIPS - Devel mailing list archive at Nabble.com.



From rod at racequeen.ph  Thu Feb 19 09:33:22 2009
From: rod at racequeen.ph (bay2x1)
Date: Thu, 19 Feb 2009 00:33:22 -0800 (PST)
Subject: [OpenSIPS-Devel]  Opensips 1.5 error
Message-ID: <1235032402511-2351872.post@n2.nabble.com>


Any hint on this problem would be appreciated.

Feb 19 16:30:48 [6336] INFO:registrar:mod_init: initializing...
Feb 19 16:30:48 [6336] INFO:textops:mod_init: initializing...
Feb 19 16:30:48 [6336] INFO:xlog:mod_init: initializing...
Feb 19 16:30:48 [6336] INFO:siptrace:mod_init: initializing...
Feb 19 16:30:48 [6336] INFO:acc:mod_init: initializing...
Feb 19 16:30:48 [6336] INFO:dialog:mod_init: Dialog module - initializing
Feb 19 16:30:48 [6336] INFO:auth:mod_init: initializing...
Feb 19 16:30:48 [6336] INFO:auth_db:mod_init: initializing...
Feb 19 16:30:48 [6336] INFO:core:probe_max_receive_buffer: using a UDP
receive buffer of 255 kb
Feb 19 16:30:48 [6336] INFO:core:probe_max_receive_buffer: using a UDP
receive buffer of 255 kb
Feb 19 16:30:48 [6336] INFO:core:probe_max_receive_buffer: using a UDP
receive buffer of 255 kb
Feb 19 16:30:48 [6336] ERROR:core:tcp_init: bind(7, 0x8182bdc, 16) on
127.0.0.1:5060 : Address already in use

-- 
View this message in context: http://n2.nabble.com/Opensips-1.5-error-tp2351872p2351872.html
Sent from the OpenSIPS - Devel mailing list archive at Nabble.com.



From dan at ag-projects.com  Wed Feb 25 10:44:29 2009
From: dan at ag-projects.com (Dan Pascu)
Date: Wed, 25 Feb 2009 09:44:29 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[5357]
	trunk/modules/nat_traversal/nat_traversal.c
Message-ID: <E1LcGJZ-0005Xh-By@dn4whf1.ch3.sourceforge.com>

Revision: 5357
          http://opensips.svn.sourceforge.net/opensips/?rev=5357&view=rev
Author:   dan_pascu
Date:     2009-02-25 09:44:29 +0000 (Wed, 25 Feb 2009)

Log Message:
-----------
Do not fix contact, only if both IP and port are the same

Modified Paths:
--------------
    trunk/modules/nat_traversal/nat_traversal.c


This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site.


From dan at ag-projects.com  Wed Feb 25 10:46:09 2009
From: dan at ag-projects.com (Dan Pascu)
Date: Wed, 25 Feb 2009 09:46:09 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[5358]
 branches/1.4/modules/nat_traversal/ nat_traversal.c
Message-ID: <E1LcGLB-0005ZB-0n@dn4whf1.ch3.sourceforge.com>

Revision: 5358
          http://opensips.svn.sourceforge.net/opensips/?rev=5358&view=rev
Author:   dan_pascu
Date:     2009-02-25 09:46:08 +0000 (Wed, 25 Feb 2009)

Log Message:
-----------
Do not fix contact, only if both IP and port are the same

Modified Paths:
--------------
    branches/1.4/modules/nat_traversal/nat_traversal.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 Feb 25 11:44:44 2009
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 25 Feb 2009 10:44:44 +0000
Subject: [OpenSIPS-Devel] [ opensips-Bugs-2591935 ] Error in sending NOTIFY
	for PUBLISH in RLS mode
Message-ID: <E1LcHFs-00049w-EM@665xhf1.ch3.sourceforge.com>

Bugs item #2591935, was opened at 2009-02-12 08:31
Message generated for change (Comment added) made by anca_vamanu
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=2591935&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: Nathan (rmnathan)
Assigned to: Anca Vamanu (anca_vamanu)
Summary: Error in sending NOTIFY for PUBLISH in RLS mode

Initial Comment:
Hi
When opensips got publish for the user(say E1_1) which has in two list subscriptions, it is sending notify to one user only.
For example:
UE2_1 list will have 2 entry uri like E1_1,E1_2
UE2_2 list will have 2 entry uri like E1_2,E1_1

S2_1 subscribe to UE2_1
S2_2 subscribe to UE2_2
If E1_1 send publish, opensips sends notify to S2_1 only. But it should send notify to S2_2 too.

Please find the attached pcap file for detailed call flow.

Regards,
rmnathan


----------------------------------------------------------------------

>Comment By: Anca Vamanu (anca_vamanu)
Date: 2009-02-25 12:44

Message:
Hi Nathan,

I have looked in the trace and for me it looks perfectly ok.

I don't understand what you say is wrong.8.

 
   ' iii) from s3-1 to c3-1 this is not correct. it should send from s3-1
to c3-2 '

    You are referring to message number 65 ( or 71 which is a
retransmission of 65), right? And you what to say that the To header is
wrong? 
If this is true, then you are wrong. The To header is exactly the same as
in the initial Subscribe received from the proxy. Please do filter on
Call-ID and check this yourself.     
   
    'iV) from s3-2 to c3-2 this is not correct. it should send from s3-2
to c3-1'
The same here.

regards,
Anca



----------------------------------------------------------------------

Comment By: Nathan (rmnathan)
Date: 2009-02-24 17:19

Message:
Hi Anca,

For the same setup
Test setup details
IMS UE1 192.168.165.151:5070
IMS UE2 192.168.165.152:5075
Proxy - SCSCF (192.168.166.150:50602)
Opensips(presence server) (10.6.2.246:5060)
RLS (10.6.2.246:5060)

The difference is two users in the IMS UE1 users list

IMS UE1 has two users
1.c3-1 which has s3-1 in list

<?xml version="1.0" encoding="UTF-8"?>
 <rls-services>
 <service uri="sip:c3-1_list at 10.6.2.246">
   <list name="c3-1">
    <entry uri="sip:s3-1 at 10.6.2.246"/>
    <entry uri="sip:s3-2 at 10.6.2.246"/>
   </list>
   <packages>
    <package>presence</package>
   </packages>
  </service>


2.c3-2 which has also s3-1 in list

<?xml version="1.0" encoding="UTF-8"?>
 <rls-services>
 <service uri="sip:c3-2_list at 10.6.2.246">
   <list name="c3-2">
    <entry uri="sip:s3-1 at 10.6.2.246"/>
    <entry uri="sip:s3-2 at 10.6.2.246"/>
   </list>
   <packages>
    <package>presence</package>
   </packages>
  </service>
 </rls-services>


IMS UE2 has one user
1.s3-1 ( this is only to send publish)
2.s3-2 (this is only to send publish)

call flow description
=====================
1.IMS UE1 ie(c3-1 and c3-2) will send subcribe to their list
2. Presence server that receives the Subscribe messages sent by the rls
server for the list subscription because the users
  in the list are same domain of presence server. So RLS server sends
subscribe, 200 ok for subscribe , Notify and 200 ok
  for notify to presence server(ie to itself because opensips and RLS
server running on same IP: 10.6.2.246)
3. After got 200 ok for subscribe and notify  for IMS UE1 users
4. Send subscribe from IMS UE2 (ie s3-1 to c3-1 & s3-2 to c3-2) . This is
just to send publish.
5. Then send publish from s3-1 and s3-2  ie from IMS UE2.
6. After got publish RLS server should generate notify to c3-1 and c3-2
because c3-1 & c3-2 have subscribed to s3-1 and s3-2
7. From captured trace RLS server sends notify and 200 ok for notify to
presence server 
Analysis
=========
8. Then after that RLS sends notify to IMS UE1
    i) from s3-1 to c3-1
    ii) from s3-2 to c3-2
    iii) from s3-1 to c3-1 this is not correct. it should send from s3-1
to c3-2
    iV) from s3-2 to c3-2 this is not correct. it should send from s3-2 to
c3-1

Please find captured trace also.

Regards
rmnathan

----------------------------------------------------------------------

Comment By: Nathan (rmnathan)
Date: 2009-02-24 15:44

Message:
Hi,
Test setup details
IMS UE1 192.168.165.151:5070
IMS UE2  192.168.165.152:5075
Proxy - SCSCF (192.168.166.150:50602)
Opensips(presence server) (10.6.2.246:5060) 
RLS (10.6.2.246:5060)



----------------------------------------------------------------------

Comment By: Nathan (rmnathan)
Date: 2009-02-24 15:37

Message:
Hi Anca

Test setup description:
======================

IMS UE1
192.168.165.151:5070
				Proxy - SCSCF            ----  Opensips(presence server)   ---- RLS
server
			  (192.168.166.150:50602)	       (10.6.2.246:5060)               
(10.6.2.246:5060)
IMS UE2
192.168.165.152:5075


IMS UE1 has two users 
1.c3-1 which has s3-1 in list

<?xml version="1.0" encoding="UTF-8"?>
 <rls-services>
 <service uri="sip:c3-1_list at 10.6.2.246">
   <list name="c3-1">
    <entry uri="sip:s3-1 at 10.6.2.246"/>

   </list>
   <packages>
    <package>presence</package>
   </packages>
  </service>
 </rls-services>

2.c3-2 which has also s3-1 in list

<?xml version="1.0" encoding="UTF-8"?>
 <rls-services>
 <service uri="sip:c3-2_list at 10.6.2.246">
   <list name="c3-2">
    <entry uri="sip:s3-1 at 10.6.2.246"/>

   </list>
   <packages>
    <package>presence</package>
   </packages>
  </service>
 </rls-services>

IMS UE2 has one user
1.s3-1 ( this is only to send publish)


call flow description
=====================
1.IMS UE1 ie(c3-1 and c3-2) will send subcribe to their list
2. Presence server that receives the Subscribe messages sent by the rls
server for the list subscription because the users
  in the list are same domain of presence server. So RLS server sends
subscribe, 200 ok for subscribe , Notify and 200 ok
  for notify to presence server(ie to itself because opensips and RLS
server running on same IP: 10.6.2.246)
3. After got 200 ok for subscribe and notify  for IMS UE1 users
4. Send subscribe from IMS UE2 (ie s3-1 to c3-1) . This is just to send
publish.
5. Then send publish from s3-1 ie from IMS UE2. 
6. After got publish RLS server should generate notify to c3-1 and c3-2
because c3-1 & c3-2 have subscribed to s3-1 
7. From captured trace RLS server sends notify and 200 ok for notify to
presence server (please explain why this is sending notify to opensips)
8. Then after that RLS sends notify to IMS UE1

9. refreshed Publish from IMS UE2
10 Removed Publish  from IMS UE2


For your queries
================
do you use a presence server that receives the
Subscribe messages sent by the rls server and also Publish messages from
the clients?

yes presence server receives the subscribe messages sent by the rls
server. The publish from clients (in this case from s3-1 (IMS UE2)

2.you send the Subscribes directly to the clients and they
reply with Notifies?
No. the subscribes sends to presence server by the rls server.

Please let me know if you want more information.
Please find captured trace also.

Regards
rmnathan


----------------------------------------------------------------------

Comment By: Anca Vamanu (anca_vamanu)
Date: 2009-02-24 14:52

Message:
Hi Rmnathan,

If you really want to help me figure out what your problem is you have to
send simpler traces. Your trace is impossible to analize - you have 8 lists
with different names, but there are 4 pairs having the same content - so
there are actually only 4 unique lists. Then you use in 'From' header of
the SUBSCRIBE not the name of the list but anther uri - this is not
important in the SIP logic - but it makes impossible for me to follow the
messages since the Notifies that the RLS sends and receives will have the
same To and From headers.
Please if you want to help run a simpler case - only two Subscriptions to
lists that can have different names but the same content. 
One more question - do you use a presence server that receives the
Subscribe messages sent by the rls server and also Publish messages from
the clients? Or you send the Subscribes directly to the clients and they
reply with Notifies?
Please also include a description with the entities in the scenario and
the IP address and port they run at.

Thanks,
Anca


----------------------------------------------------------------------

Comment By: Anca Vamanu (anca_vamanu)
Date: 2009-02-24 13:29

Message:
Hi Rmnathan,

If you really want to help me figure out what your problem is you have to
send simpler traces. Your trace is impossible to analize - you have 8 lists
with different names, but there are 4 pairs having the same content - so
there are actually only 4 unique lists. Then you use in 'From' header of
the SUBSCRIBE not the name of the list but anther uri - this is not
important in the SIP logic - but it makes impossible for me to follow the
messages since the Notifies that the RLS sends and receives will have the
same To and From headers.
Please if you want to help run a simpler case - only two Subscriptions to
lists that can have different names but the same content. 
One more question - do you use a presence server that receives the
Subscribe messages sent by the rls server and also Publish messages from
the clients? Or you send the Subscribes directly to the clients and they
reply with Notifies?
Please also include a description with the entities in the scenario and
the IP address and port they run at.

Thanks,
Anca


----------------------------------------------------------------------

Comment By: Nathan (rmnathan)
Date: 2009-02-24 12:43

Message:
Hi Anca,
After that i have tested. still the issue is not fixed. Now opensips is
generating notify for all the users(for first user) in the list but it
always sending to first user in the list only not for other users. 

Please see the attached pcap file.

Regards
rmnathan



----------------------------------------------------------------------

Comment By: Anca Vamanu (anca_vamanu)
Date: 2009-02-24 11:49

Message:
Hi Rmnathan,

A change was made for many tables - changing varchar type to char and
since the structure was changed, the version of the tables was increased.
You need to get the new mysql script and recreate the table and also
update the version for rls_presentity table in 'version' table. However
since there are many tables for which the version was increased I would
recommend recreating the whole database.

regards,
Anca

----------------------------------------------------------------------

Comment By: Nathan (rmnathan)
Date: 2009-02-24 08:23

Message:
Hi Anca,
I tried with latest trunk 5354 build. while starting opensips i got
following error message
stinbng46:/usr/local/trunk# /usr/local/sbin/opensips
Listening on
             udp: 10.6.2.246 [10.6.2.246]:5060
Aliases:
             udp: stinbng46:5060

stinbng46:/usr/local/trunk# Feb 24 11:46:35 [2520]
ERROR:core:db_check_table_version: invalid version 0 for table
rls_presentity found, expected 1
Feb 24 11:46:35 [2520] ERROR:rls:mod_init: error during table version
check.
Feb 24 11:46:35 [2520] ERROR:core:init_mod: failed to initialize module
rls
Feb 24 11:46:35 [2520] ERROR:core:main: error while initializing modules
i have   rls_presentity table also in opensips database.
mysql> desc rls_presentity
    -> ;
+----------------+------------------+------+-----+---------+----------------+
| Field          | Type             | Null | Key | Default | Extra        
 |
+----------------+------------------+------+-----+---------+----------------+
| id             | int(10) unsigned | NO   | PRI | NULL    |
auto_increment |
| rlsubs_did     | char(255)        | NO   | MUL |         |              
 |
| resource_uri   | char(128)        | NO   |     |         |              
 |
| content_type   | char(64)         | NO   |     |         |              
 |
| presence_state | blob             | NO   |     |         |              
 |
| expires        | int(11)          | NO   |     |         |              
 |
| updated        | int(11)          | NO   | MUL |         |              
 |
| auth_state     | int(11)          | NO   |     |         |              
 |
| reason         | char(64)         | NO   |     |         |              
 |
+----------------+------------------+------+-----+---------+----------------+
9 rows in set (0.00 sec)

I have changed and tried table version in script also 
INSERT INTO version (table_name, table_version) values
('rls_presentity','1');
  CREATE TABLE rls_presentity (
      id INT(10) UNSIGNED AUTO_INCREMENT PRIMARY KEY NOT NULL,
      rlsubs_did CHAR(255) NOT NULL,
      resource_uri CHAR(128) NOT NULL,
      content_type CHAR(64) NOT NULL,
      presence_state BLOB NOT NULL,
      expires INT(11) NOT NULL,
      updated INT(11) NOT NULL,
      auth_state INT(11) NOT NULL,
      reason CHAR(64) NOT NULL,
      CONSTRAINT rls_presentity_idx UNIQUE (rlsubs_did, resource_uri)
  ) ENGINE=MyISAM;
Again i got the same error.

Regards
rmnathan

----------------------------------------------------------------------

Comment By: Anca Vamanu (anca_vamanu)
Date: 2009-02-18 17:17

Message:
Hi Rmnathan,

Thank you for this report.
Indeed, you were right- not all update Notifies were sent due to a bug in
the code. I have fixed it. Please update to the new svn version and test it
yourself. I will wait for your feedback before closing this bug report.

regards,
Anca



----------------------------------------------------------------------

Comment By: Anca Vamanu (anca_vamanu)
Date: 2009-02-18 17:17

Message:
Hi Rmnathan,

Thank you for this report.
Indeed, you were right- not all update Notifies were sent due to a bug in
the code. I have fixed it. Please update to the new svn version and test it
yourself. I will wait for your feedback before closing this bug report.

regards,
Anca



----------------------------------------------------------------------

Comment By: Anca Vamanu (anca_vamanu)
Date: 2009-02-18 17:16

Message:
Hi Rmnathan,

Thank you for this report.
Indeed, you were right- not all update Notifies were sent due to a bug in
the code. I have fixed it. Please update to the new svn version and test it
yourself. I will wait for your feedback before closing this bug report.

regards,
Anca



----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=2591935&group_id=232389


From noreply at sourceforge.net  Wed Feb 25 12:20:23 2009
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 25 Feb 2009 11:20:23 +0000
Subject: [OpenSIPS-Devel] [ opensips-Bugs-2634285 ] Nat_traversal:
	opensipsctl ul rm doesn't clean up keepalives
Message-ID: <E1LcHoN-0006qx-V3@665xhf1.ch3.sourceforge.com>

Bugs item #2634285, was opened at 2009-02-24 19:11
Message generated for change (Comment added) made by dan_pascu
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=2634285&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: Invalid
Priority: 5
Private: No
Submitted By: Thomas Gelf (thomas_gelf)
>Assigned to: Dan (dan_pascu)
Summary: Nat_traversal: opensipsctl ul rm doesn't clean up keepalives

Initial Comment:
Running

> opensipsctl ul rm user at domain.tld

doesn't seem to affect nat_traversal's keep-alive state.

Steps I followed to reproduce this issue:
* removed all registrations
* stopped OpenSIPS
* removed keep-alive state file
* started OpenSIPS
* booted some test device
* let devices (all of them behind NAT) REGISTER themselves
* stopped OpenSIPS, manually compared usrloc entries and keep-alive state file
* everything seemed to be fine
* restarted OpenSIPS, "ul rm" for one user, stopped OpenSIPS
* old entry is still to be found in keep-alive state file

OpenSIPS version: SVN trunk, updated this morning. If you need more tests please let me know!

Best regards,
Thomas Gelf


----------------------------------------------------------------------

>Comment By: Dan (dan_pascu)
Date: 2009-02-25 13:20

Message:
The nat_traversal module doesn't use the ul module contacts, instead it
keeps track itself of the nat entry points (ip:port). These do not have a
1:1 relationship, as a nat entry point can be used by multiple contacts. So
when a contact is removed you can say nothing about the nat entry point not
being used anymore. The nat_traversal module will remove a nat entry point
from the keepalive list only when all the reasons to keep that address
alive expire. For a registration, that means when it expires. Read the
nat_traversal documentation for a detailed explanation of its operation.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=2634285&group_id=232389


From noreply at sourceforge.net  Wed Feb 25 12:53:24 2009
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 25 Feb 2009 11:53:24 +0000
Subject: [OpenSIPS-Devel] [ opensips-Bugs-2636665 ] Bad parsing of BLOBs in
	db_postgres+patch
Message-ID: <E1LcIKK-0002xb-Mh@3bkjzd1.ch3.sourceforge.com>

Bugs item #2636665, was opened at 2009-02-25 13:53
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=2636665&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: Vasil Kolev (krokodilerian)
Assigned to: Nobody/Anonymous (nobody)
Summary: Bad parsing of BLOBs in db_postgres+patch

Initial Comment:
Excerpt from the logs:

Feb 25 11:09:20 [12106] DBG:db_postgres:db_postgres_submit_query: 0x8198488 PQsendQuery(select presentity_uri,expires,event,event_id,to_user,to_domain,watcher_username,watcher_domain,callid,to_tag,from_tag
,local_cseq,remote_cseq,record_route,socket_info,contact,local_contact,version,status,reason from active_watchers )
Feb 25 11:09:20 [12106] DBG:core:db_new_result: allocate 28 bytes for result set at 0x81984e8
Feb 25 11:09:20 [12106] DBG:db_postgres:db_postgres_fetch_result: 0x8198488 PQresultStatus(PGRES_TUPLES_OK) PQgetResult(0x9807030)
Feb 25 11:09:20 [12106] DBG:db_postgres:db_postgres_get_columns: 20 columns returned from the query
Feb 25 11:09:20 [12106] DBG:core:db_allocate_columns: allocate 320 bytes for result columns at 0x8198ae8
...
...
...
Feb 25 11:09:20 [12106] DBG:db_postgres:db_postgres_get_columns: RES_NAMES(0x8198bf0)[13]=[record_route]
Feb 25 11:09:20 [12106] DBG:db_postgres:db_postgres_get_columns: use DB_BLOB result type
...
...
...
Feb 25 11:09:20 [12106] DBG:db_postgres:db_postgres_convert_rows: allocated 0 bytes for row_buf[13] at 0x8198c88
Feb 25 11:09:20 [12106] DBG:db_postgres:db_postgres_convert_rows: [0][13] Column[record_route]=[]
...
...
...
Feb 25 11:09:20 [12106] DBG:db_postgres:db_postgres_str2val: converting BLOB []
Feb 25 11:09:20 [12106] DBG:db_postgres:db_postgres_str2val: got blob len 0
...
...
...
Feb 25 11:09:20 [12106] DBG:db_postgres:db_postgres_convert_rows: PQgetvalue(0x8198488,1,13)=[<98>!<F7><B7><98>!<F7><B7>^P]
Feb 25 11:09:20 [12106] DBG:db_postgres:db_postgres_convert_rows: allocated 9 bytes for row_buf[13] at 0x819a7a8

Patch should be self-explanatory :)

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=2636665&group_id=232389


From noreply at sourceforge.net  Wed Feb 25 13:14:41 2009
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 25 Feb 2009 12:14:41 +0000
Subject: [OpenSIPS-Devel] [ opensips-Bugs-2636710 ] rr (loose_route) should
	take aliases from domain module
Message-ID: <E1LcIev-0003U2-Aq@g45xhf1.ch3.sourceforge.com>

Bugs item #2636710, was opened at 2009-02-25 13:14
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=2636710&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: Thomas Gelf (thomas_gelf)
Assigned to: Nobody/Anonymous (nobody)
Summary: rr (loose_route) should take aliases from domain module

Initial Comment:
OpenSIPS 1.5 (SVN, today) still needs aliases to be defined manually using alias=... - otherwise loose_route() doesn't detect them as "local", even if defined in the domain table.

Best regards,
Thomas Gelf


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=2636710&group_id=232389


From noreply at sourceforge.net  Wed Feb 25 14:02:40 2009
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 25 Feb 2009 13:02:40 +0000
Subject: [OpenSIPS-Devel] [ opensips-Bugs-2591935 ] Error in sending NOTIFY
	for PUBLISH in RLS mode
Message-ID: <E1LcJPM-0005c3-3N@565xhf1.ch3.sourceforge.com>

Bugs item #2591935, was opened at 2009-02-12 12:01
Message generated for change (Comment added) made by rmnathan
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=2591935&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: Nathan (rmnathan)
Assigned to: Anca Vamanu (anca_vamanu)
Summary: Error in sending NOTIFY for PUBLISH in RLS mode

Initial Comment:
Hi
When opensips got publish for the user(say E1_1) which has in two list subscriptions, it is sending notify to one user only.
For example:
UE2_1 list will have 2 entry uri like E1_1,E1_2
UE2_2 list will have 2 entry uri like E1_2,E1_1

S2_1 subscribe to UE2_1
S2_2 subscribe to UE2_2
If E1_1 send publish, opensips sends notify to S2_1 only. But it should send notify to S2_2 too.

Please find the attached pcap file for detailed call flow.

Regards,
rmnathan


----------------------------------------------------------------------

Comment By: Nathan (rmnathan)
Date: 2009-02-25 18:32

Message:
Hi Anca,
Thanks for your reply.
I can't understand one thing.

Step 1:
c3-1_list has two users as s3-1 and s3-2
c3-2_list has two users as s3-1 and s3-2

Step 2:
c3-1 subscribe to c3-1_list
c3-2 subscribe to c3-2_list

Step 3:
If RLS gets publish from s3-1
it is sending NOTIFY to c3-1 one only. It is not sending  NOTIFY to c3-2.
can u explain why it is not sending NOTIFY to c3-2.

My doubt is s3-1 is in both the lists (ie c3-1 and c3-2). But RLS sending
notify to c3-1 one only. It is not sending to c3-2.

Regards
rmnathan


 

----------------------------------------------------------------------

Comment By: Anca Vamanu (anca_vamanu)
Date: 2009-02-25 16:14

Message:
Hi Nathan,

I have looked in the trace and for me it looks perfectly ok.

I don't understand what you say is wrong.8.

 
   ' iii) from s3-1 to c3-1 this is not correct. it should send from s3-1
to c3-2 '

    You are referring to message number 65 ( or 71 which is a
retransmission of 65), right? And you what to say that the To header is
wrong? 
If this is true, then you are wrong. The To header is exactly the same as
in the initial Subscribe received from the proxy. Please do filter on
Call-ID and check this yourself.     
   
    'iV) from s3-2 to c3-2 this is not correct. it should send from s3-2
to c3-1'
The same here.

regards,
Anca



----------------------------------------------------------------------

Comment By: Nathan (rmnathan)
Date: 2009-02-24 20:49

Message:
Hi Anca,

For the same setup
Test setup details
IMS UE1 192.168.165.151:5070
IMS UE2 192.168.165.152:5075
Proxy - SCSCF (192.168.166.150:50602)
Opensips(presence server) (10.6.2.246:5060)
RLS (10.6.2.246:5060)

The difference is two users in the IMS UE1 users list

IMS UE1 has two users
1.c3-1 which has s3-1 in list

<?xml version="1.0" encoding="UTF-8"?>
 <rls-services>
 <service uri="sip:c3-1_list at 10.6.2.246">
   <list name="c3-1">
    <entry uri="sip:s3-1 at 10.6.2.246"/>
    <entry uri="sip:s3-2 at 10.6.2.246"/>
   </list>
   <packages>
    <package>presence</package>
   </packages>
  </service>


2.c3-2 which has also s3-1 in list

<?xml version="1.0" encoding="UTF-8"?>
 <rls-services>
 <service uri="sip:c3-2_list at 10.6.2.246">
   <list name="c3-2">
    <entry uri="sip:s3-1 at 10.6.2.246"/>
    <entry uri="sip:s3-2 at 10.6.2.246"/>
   </list>
   <packages>
    <package>presence</package>
   </packages>
  </service>
 </rls-services>


IMS UE2 has one user
1.s3-1 ( this is only to send publish)
2.s3-2 (this is only to send publish)

call flow description
=====================
1.IMS UE1 ie(c3-1 and c3-2) will send subcribe to their list
2. Presence server that receives the Subscribe messages sent by the rls
server for the list subscription because the users
  in the list are same domain of presence server. So RLS server sends
subscribe, 200 ok for subscribe , Notify and 200 ok
  for notify to presence server(ie to itself because opensips and RLS
server running on same IP: 10.6.2.246)
3. After got 200 ok for subscribe and notify  for IMS UE1 users
4. Send subscribe from IMS UE2 (ie s3-1 to c3-1 & s3-2 to c3-2) . This is
just to send publish.
5. Then send publish from s3-1 and s3-2  ie from IMS UE2.
6. After got publish RLS server should generate notify to c3-1 and c3-2
because c3-1 & c3-2 have subscribed to s3-1 and s3-2
7. From captured trace RLS server sends notify and 200 ok for notify to
presence server 
Analysis
=========
8. Then after that RLS sends notify to IMS UE1
    i) from s3-1 to c3-1
    ii) from s3-2 to c3-2
    iii) from s3-1 to c3-1 this is not correct. it should send from s3-1
to c3-2
    iV) from s3-2 to c3-2 this is not correct. it should send from s3-2 to
c3-1

Please find captured trace also.

Regards
rmnathan

----------------------------------------------------------------------

Comment By: Nathan (rmnathan)
Date: 2009-02-24 19:14

Message:
Hi,
Test setup details
IMS UE1 192.168.165.151:5070
IMS UE2  192.168.165.152:5075
Proxy - SCSCF (192.168.166.150:50602)
Opensips(presence server) (10.6.2.246:5060) 
RLS (10.6.2.246:5060)



----------------------------------------------------------------------

Comment By: Nathan (rmnathan)
Date: 2009-02-24 19:07

Message:
Hi Anca

Test setup description:
======================

IMS UE1
192.168.165.151:5070
				Proxy - SCSCF            ----  Opensips(presence server)   ---- RLS
server
			  (192.168.166.150:50602)	       (10.6.2.246:5060)               
(10.6.2.246:5060)
IMS UE2
192.168.165.152:5075


IMS UE1 has two users 
1.c3-1 which has s3-1 in list

<?xml version="1.0" encoding="UTF-8"?>
 <rls-services>
 <service uri="sip:c3-1_list at 10.6.2.246">
   <list name="c3-1">
    <entry uri="sip:s3-1 at 10.6.2.246"/>

   </list>
   <packages>
    <package>presence</package>
   </packages>
  </service>
 </rls-services>

2.c3-2 which has also s3-1 in list

<?xml version="1.0" encoding="UTF-8"?>
 <rls-services>
 <service uri="sip:c3-2_list at 10.6.2.246">
   <list name="c3-2">
    <entry uri="sip:s3-1 at 10.6.2.246"/>

   </list>
   <packages>
    <package>presence</package>
   </packages>
  </service>
 </rls-services>

IMS UE2 has one user
1.s3-1 ( this is only to send publish)


call flow description
=====================
1.IMS UE1 ie(c3-1 and c3-2) will send subcribe to their list
2. Presence server that receives the Subscribe messages sent by the rls
server for the list subscription because the users
  in the list are same domain of presence server. So RLS server sends
subscribe, 200 ok for subscribe , Notify and 200 ok
  for notify to presence server(ie to itself because opensips and RLS
server running on same IP: 10.6.2.246)
3. After got 200 ok for subscribe and notify  for IMS UE1 users
4. Send subscribe from IMS UE2 (ie s3-1 to c3-1) . This is just to send
publish.
5. Then send publish from s3-1 ie from IMS UE2. 
6. After got publish RLS server should generate notify to c3-1 and c3-2
because c3-1 & c3-2 have subscribed to s3-1 
7. From captured trace RLS server sends notify and 200 ok for notify to
presence server (please explain why this is sending notify to opensips)
8. Then after that RLS sends notify to IMS UE1

9. refreshed Publish from IMS UE2
10 Removed Publish  from IMS UE2


For your queries
================
do you use a presence server that receives the
Subscribe messages sent by the rls server and also Publish messages from
the clients?

yes presence server receives the subscribe messages sent by the rls
server. The publish from clients (in this case from s3-1 (IMS UE2)

2.you send the Subscribes directly to the clients and they
reply with Notifies?
No. the subscribes sends to presence server by the rls server.

Please let me know if you want more information.
Please find captured trace also.

Regards
rmnathan


----------------------------------------------------------------------

Comment By: Anca Vamanu (anca_vamanu)
Date: 2009-02-24 18:22

Message:
Hi Rmnathan,

If you really want to help me figure out what your problem is you have to
send simpler traces. Your trace is impossible to analize - you have 8 lists
with different names, but there are 4 pairs having the same content - so
there are actually only 4 unique lists. Then you use in 'From' header of
the SUBSCRIBE not the name of the list but anther uri - this is not
important in the SIP logic - but it makes impossible for me to follow the
messages since the Notifies that the RLS sends and receives will have the
same To and From headers.
Please if you want to help run a simpler case - only two Subscriptions to
lists that can have different names but the same content. 
One more question - do you use a presence server that receives the
Subscribe messages sent by the rls server and also Publish messages from
the clients? Or you send the Subscribes directly to the clients and they
reply with Notifies?
Please also include a description with the entities in the scenario and
the IP address and port they run at.

Thanks,
Anca


----------------------------------------------------------------------

Comment By: Anca Vamanu (anca_vamanu)
Date: 2009-02-24 16:59

Message:
Hi Rmnathan,

If you really want to help me figure out what your problem is you have to
send simpler traces. Your trace is impossible to analize - you have 8 lists
with different names, but there are 4 pairs having the same content - so
there are actually only 4 unique lists. Then you use in 'From' header of
the SUBSCRIBE not the name of the list but anther uri - this is not
important in the SIP logic - but it makes impossible for me to follow the
messages since the Notifies that the RLS sends and receives will have the
same To and From headers.
Please if you want to help run a simpler case - only two Subscriptions to
lists that can have different names but the same content. 
One more question - do you use a presence server that receives the
Subscribe messages sent by the rls server and also Publish messages from
the clients? Or you send the Subscribes directly to the clients and they
reply with Notifies?
Please also include a description with the entities in the scenario and
the IP address and port they run at.

Thanks,
Anca


----------------------------------------------------------------------

Comment By: Nathan (rmnathan)
Date: 2009-02-24 16:13

Message:
Hi Anca,
After that i have tested. still the issue is not fixed. Now opensips is
generating notify for all the users(for first user) in the list but it
always sending to first user in the list only not for other users. 

Please see the attached pcap file.

Regards
rmnathan



----------------------------------------------------------------------

Comment By: Anca Vamanu (anca_vamanu)
Date: 2009-02-24 15:19

Message:
Hi Rmnathan,

A change was made for many tables - changing varchar type to char and
since the structure was changed, the version of the tables was increased.
You need to get the new mysql script and recreate the table and also
update the version for rls_presentity table in 'version' table. However
since there are many tables for which the version was increased I would
recommend recreating the whole database.

regards,
Anca

----------------------------------------------------------------------

Comment By: Nathan (rmnathan)
Date: 2009-02-24 11:53

Message:
Hi Anca,
I tried with latest trunk 5354 build. while starting opensips i got
following error message
stinbng46:/usr/local/trunk# /usr/local/sbin/opensips
Listening on
             udp: 10.6.2.246 [10.6.2.246]:5060
Aliases:
             udp: stinbng46:5060

stinbng46:/usr/local/trunk# Feb 24 11:46:35 [2520]
ERROR:core:db_check_table_version: invalid version 0 for table
rls_presentity found, expected 1
Feb 24 11:46:35 [2520] ERROR:rls:mod_init: error during table version
check.
Feb 24 11:46:35 [2520] ERROR:core:init_mod: failed to initialize module
rls
Feb 24 11:46:35 [2520] ERROR:core:main: error while initializing modules
i have   rls_presentity table also in opensips database.
mysql> desc rls_presentity
    -> ;
+----------------+------------------+------+-----+---------+----------------+
| Field          | Type             | Null | Key | Default | Extra        
 |
+----------------+------------------+------+-----+---------+----------------+
| id             | int(10) unsigned | NO   | PRI | NULL    |
auto_increment |
| rlsubs_did     | char(255)        | NO   | MUL |         |              
 |
| resource_uri   | char(128)        | NO   |     |         |              
 |
| content_type   | char(64)         | NO   |     |         |              
 |
| presence_state | blob             | NO   |     |         |              
 |
| expires        | int(11)          | NO   |     |         |              
 |
| updated        | int(11)          | NO   | MUL |         |              
 |
| auth_state     | int(11)          | NO   |     |         |              
 |
| reason         | char(64)         | NO   |     |         |              
 |
+----------------+------------------+------+-----+---------+----------------+
9 rows in set (0.00 sec)

I have changed and tried table version in script also 
INSERT INTO version (table_name, table_version) values
('rls_presentity','1');
  CREATE TABLE rls_presentity (
      id INT(10) UNSIGNED AUTO_INCREMENT PRIMARY KEY NOT NULL,
      rlsubs_did CHAR(255) NOT NULL,
      resource_uri CHAR(128) NOT NULL,
      content_type CHAR(64) NOT NULL,
      presence_state BLOB NOT NULL,
      expires INT(11) NOT NULL,
      updated INT(11) NOT NULL,
      auth_state INT(11) NOT NULL,
      reason CHAR(64) NOT NULL,
      CONSTRAINT rls_presentity_idx UNIQUE (rlsubs_did, resource_uri)
  ) ENGINE=MyISAM;
Again i got the same error.

Regards
rmnathan

----------------------------------------------------------------------

Comment By: Anca Vamanu (anca_vamanu)
Date: 2009-02-18 20:47

Message:
Hi Rmnathan,

Thank you for this report.
Indeed, you were right- not all update Notifies were sent due to a bug in
the code. I have fixed it. Please update to the new svn version and test it
yourself. I will wait for your feedback before closing this bug report.

regards,
Anca



----------------------------------------------------------------------

Comment By: Anca Vamanu (anca_vamanu)
Date: 2009-02-18 20:47

Message:
Hi Rmnathan,

Thank you for this report.
Indeed, you were right- not all update Notifies were sent due to a bug in
the code. I have fixed it. Please update to the new svn version and test it
yourself. I will wait for your feedback before closing this bug report.

regards,
Anca



----------------------------------------------------------------------

Comment By: Anca Vamanu (anca_vamanu)
Date: 2009-02-18 20:46

Message:
Hi Rmnathan,

Thank you for this report.
Indeed, you were right- not all update Notifies were sent due to a bug in
the code. I have fixed it. Please update to the new svn version and test it
yourself. I will wait for your feedback before closing this bug report.

regards,
Anca



----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=2591935&group_id=232389


From anca at opensips.org  Wed Feb 25 17:42:52 2009
From: anca at opensips.org (Anca Vamanu)
Date: Wed, 25 Feb 2009 16:42:52 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[5359] trunk/modules/presence
Message-ID: <E1LcMqS-0006Ay-Om@74yxhf1.ch3.sourceforge.com>

Revision: 5359
          http://opensips.svn.sourceforge.net/opensips/?rev=5359&view=rev
Author:   anca_vamanu
Date:     2009-02-25 16:42:52 +0000 (Wed, 25 Feb 2009)

Log Message:
-----------
- fixed a bug introduced in a recent commit - set the right expires value when inserting dialog in database
- took out some more sql prepare statements usages

Modified Paths:
--------------
    trunk/modules/presence/notify.c
    trunk/modules/presence/presence.c
    trunk/modules/presence/subscribe.c


This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site.


From anca at opensips.org  Wed Feb 25 17:43:45 2009
From: anca at opensips.org (Anca Vamanu)
Date: Wed, 25 Feb 2009 16:43:45 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[5360]
	trunk/modules/presence_xml/notify_body.c
Message-ID: <E1LcMrJ-0006Bk-2n@74yxhf1.ch3.sourceforge.com>

Revision: 5360
          http://opensips.svn.sourceforge.net/opensips/?rev=5360&view=rev
Author:   anca_vamanu
Date:     2009-02-25 16:43:44 +0000 (Wed, 25 Feb 2009)

Log Message:
-----------
- fixed a bug when aggregating presence bodies - reported by Oren K in bug #2538399

Modified Paths:
--------------
    trunk/modules/presence_xml/notify_body.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 Feb 25 17:44:28 2009
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 25 Feb 2009 16:44:28 +0000
Subject: [OpenSIPS-Devel] [ opensips-Bugs-2538399 ] Bug in presence when
	using fallback2db
Message-ID: <E1LcMs0-0005B7-3g@665xhf1.ch3.sourceforge.com>

Bugs item #2538399, was opened at 2009-01-26 21:39
Message generated for change (Comment added) made by anca_vamanu
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=2538399&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: Oren K (oren_k)
Assigned to: Anca Vamanu (anca_vamanu)
Summary: Bug in presence when using fallback2db

Initial Comment:
Hi,

While using the presence module, I run this scenario:

a. user1 SUBSCRIBE's to presence of user2
(subscription is now pending)

b. user2 allows user1 in pres-rules
(refreshWatchers is called, subscription is now active. user1 receives a NOTIFY from presence server with user2's current tuple and Subscription-State: active)

c. user2 PUBLISH'es a new presence tuple
-- at this point presence server should NOTIFY user1 of the new presence but it doesn't (that's the bug).


My modparams:

modparam("presence|presence_xml", "db_url", "mysql://root at localhost/opensips")

modparam("presence", "server_address", "sip:presence.example.com:10500")

modparam("presence", "fallback2db", 1)
modparam("presence", "clean_period", 30)


What I see in the debug trace is that get_subs_dialog (from notify.c) can't find any dialogs in the database, and all those in the subs hash are flagged NO_UPDATEDB_FLAG. This is probably what's causing the problem. 
Strangely, in the above scenario if user1 un-SUBSCRIBEs and re-SUBSCRIBEs to user2's presence - it does receive notifications.

Regards,
Oren K.

----------------------------------------------------------------------

>Comment By: Anca Vamanu (anca_vamanu)
Date: 2009-02-25 18:44

Message:
Hi Oren,

I have tested myself and fixed it. I hope it also works for you. Please
update, test and reply.

regards,
Anca

----------------------------------------------------------------------

Comment By: Oren K (oren_k)
Date: 2009-02-24 16:44

Message:
It would appear that OpenSIPS does not reply in a timely manner:

Feb 23 12:34:58 openims /usr/local/sbin/opensips[3091]:
DBG:tm:utimer_routine: timer routine:4,tl=0xb6183d1c next=(nil),
timeout=974500000
Feb 23 12:35:01 openims opensips-mi-proxy[2368]: [-] error: Error while
processing command refreshWatchers (sip:user2 at openims.summit-tech.ca
presence 0): OpenSIP
S command did timeout

Strangely the first mi_refresh_watchers gets through, this exception only
happens in the second time its called. I'm attaching the logfile from this
run so you can have a look. OpenSIPS does not report any errors, but the
scenario still happens: No NOTIFY is received after user2 PUBLISHes.

----------------------------------------------------------------------

Comment By: Anca Vamanu (anca_vamanu)
Date: 2009-02-24 11:41

Message:
Hi, 

It does not help me if you say what error you get in opensips-mi-proxy. It
would have been better if you said what is the error in opensips :) .
Please look in the log, find the error and print it here.

regards, 
Anca

----------------------------------------------------------------------

Comment By: Oren K (oren_k)
Date: 2009-02-23 19:38

Message:
Thanks for your help Anca. I updated my sources from SVN and recompiled but
unfortunately the bug is still not resolved. I am still getting a crash
from opensips-mi-proxy, its the same one as on my previous comment from
Date: 2009-02-20 13:22

exceptions.ValueError: invalid literal for int() with base 10: 'OpenSIPS'

----------------------------------------------------------------------

Comment By: Anca Vamanu (anca_vamanu)
Date: 2009-02-23 15:57

Message:
Hi Oren,

I have fixed the problem with 'transformations' node. Please update and
test again.

Thanks,
Anca

----------------------------------------------------------------------

Comment By: Oren K (oren_k)
Date: 2009-02-20 20:53

Message:
also I was getting errors because I didn't have a transformations node. The
common-policy schema states that transformations isn't a must-have, and I
think opensips should treat no transformations node the same as if there
was an empty one.

<xs:element name="transformations" type="cp:extensibleType"
minOccurs="0"/>

However, adding a <transformations/> to my pres-rules had not effect on
this bug (still happens).

----------------------------------------------------------------------

Comment By: Oren K (oren_k)
Date: 2009-02-20 20:22

Message:
Something else is wrong now. mi_refresh_watchers is getting a timeout. This
didn't happen before. I'm using:
OpenXCAP 1.0.6
opensips-mi-proxy 1.0.2

Right now nothing works, not even normal scenarios.

Feb 20 13:16:22 openims opensips-mi-proxy[2368]: [-] error: Error while
processing command refreshWatchers (sip:user2 at openims.summit-tech.ca
presence 0): O
penSIPS command did timeout
Feb 20 13:16:22 openims opensips-mi-proxy[2368]: [-] Exception rendering:
Feb 20 13:16:22 openims opensips-mi-proxy[2368]: [-] Traceback (most
recent call last):
Feb 20 13:16:22 openims opensips-mi-proxy[2368]: [-]       File
"/usr/lib/python2.5/site-packages/Twisted-8.2.0_r25964-py2.5-linux-i686.egg/twisted/interne
t/defer.py", line 312, in _startRunCallbacks
Feb 20 13:16:22 openims opensips-mi-proxy[2368]: [-]        
self._runCallbacks()
Feb 20 13:16:22 openims opensips-mi-proxy[2368]: [-]       File
"/usr/lib/python2.5/site-packages/Twisted-8.2.0_r25964-py2.5-linux-i686.egg/twisted/interne
t/defer.py", line 328, in _runCallbacks
Feb 20 13:16:22 openims opensips-mi-proxy[2368]: [-]         self.result =
callback(self.result, *args, **kw)
Feb 20 13:16:22 openims opensips-mi-proxy[2368]: [-]       File
"/usr/lib/python2.5/site-packages/Twisted-8.2.0_r25964-py2.5-linux-i686.egg/twisted/interne
t/defer.py", line 289, in _continue
Feb 20 13:16:22 openims opensips-mi-proxy[2368]: [-]        
self.unpause()
Feb 20 13:16:22 openims opensips-mi-proxy[2368]: [-]       File
"/usr/lib/python2.5/site-packages/Twisted-8.2.0_r25964-py2.5-linux-i686.egg/twisted/interne
t/defer.py", line 285, in unpause
Feb 20 13:16:22 openims opensips-mi-proxy[2368]: [-]        
self._runCallbacks()
Feb 20 13:16:22 openims opensips-mi-proxy[2368]: [-]     --- <exception
caught here> ---
Feb 20 13:16:22 openims opensips-mi-proxy[2368]: [-]       File
"/usr/lib/python2.5/site-packages/Twisted-8.2.0_r25964-py2.5-linux-i686.egg/twisted/interne
t/defer.py", line 328, in _runCallbacks
Feb 20 13:16:22 openims opensips-mi-proxy[2368]: [-]         self.result =
callback(self.result, *args, **kw)
Feb 20 13:16:22 openims opensips-mi-proxy[2368]: [-]       File
"/usr/lib/python2.5/site-packages/miproxy/proxy.py", line 89, in _cbRender
Feb 20 13:16:22 openims opensips-mi-proxy[2368]: [-]         code =
int(code)
Feb 20 13:16:22 openims opensips-mi-proxy[2368]: [-]    
exceptions.ValueError: invalid literal for int() with base 10: 'OpenSIPS'


----------------------------------------------------------------------

Comment By: Anca Vamanu (anca_vamanu)
Date: 2009-02-20 14:59

Message:
Hi,

I have just made a fix. Please update, test again and reply.

Thanks,
Anca

----------------------------------------------------------------------

Comment By: Anca Vamanu (anca_vamanu)
Date: 2009-02-20 14:25

Message:
Hi Oren,

I have looked into the log file that you posted and saw that there was and
error there. There is a problem with the body of the Publish message -
which causes stopping the processing. The problem is that the code in the
presence server expects a tuple element in the body - and the body of the
last Publish message does not contain one.
I have looked up in the RFC and saw that the tuple element is in fact not
compulsory - so there is a bug in the presence code - but not the one you
reported :). 
I will fix this soon.

Thanks and regards,
Anca

----------------------------------------------------------------------

Comment By: Oren K (oren_k)
Date: 2009-02-20 01:42

Message:
Still no joy.. adding updated log and pcap for the version i compiled from
svn 1.5.0dev5-tls.

----------------------------------------------------------------------

Comment By: Anca Vamanu (anca_vamanu)
Date: 2009-02-18 18:11

Message:
Hi, 

I have just now made some changes in presence module for fallback2db case.
Can you please update to the newest svn version for 1.5 and test again?

regards,
Anca

----------------------------------------------------------------------

Comment By: Anca Vamanu (anca_vamanu)
Date: 2009-02-18 18:10

Message:
Hi, 

I have just now made some changes in presence module for fallback2db case.
Can you please update to the newest svn version for 1.5 and test again?

regards,
Anca

----------------------------------------------------------------------

Comment By: Oren K (oren_k)
Date: 2009-02-07 02:23

Message:
Hi Anca,

I've attached a debug-log and wireshark pcap file to the post. The pcap
file also contains the XCAP PUTs to change the presence rules. The only
error in the log comes from presence_xml not being able to extract a tuple
node because our client uses <pdm:person> for the presence (Same bug
happened to us when we tried with <tuple> so that's not the issue). The
things that strike me odd in presence_bug.log are:

(after step b. user2 allows user1 in pres-rules)
line 634: DBG:presence:update_pw_dialogs: found 1 matching dialogs

the module finds the watcher dialog and updates it due to refreshWatchers.
user1 receives a NOTIFY with Subscription-State:active. Now step c. user2
PUBLISH'es a new presence tuple:

line 919: DBG:core:parse_msg:  method:  <PUBLISH>

everything looks okay BUT:

line 1087: DBG:presence:get_subs_db: The query for subscribtion for [uri]=
sip:user2 at openims.summit-tech.ca for [event]= presence returned no result
line 1110: DBG:presence:get_subs_dialog: s->db_flag== UPDATEDB_FLAG
line 1111: DBG:presence:get_subs_dialog: found 0 dialogs( 0 in database
and 0 in hash_table)
line 1112: DBG:presence:publ_notify: Could not find subs_dialog

..suddenly there are no subscribers?

Thanks.


----------------------------------------------------------------------

Comment By: Anca Vamanu (anca_vamanu)
Date: 2009-02-06 20:14

Message:
Hi Oren,

I have just downloaded myself the release and tested and the scenario that
you described works. 
Do you notice any error in your log file?

regards,
Anca

----------------------------------------------------------------------

Comment By: Oren K (oren_k)
Date: 2009-02-01 18:41

Message:
Sorry I forgot to login, that comment is from me :)

----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2009-01-28 17:12

Message:
Thanks for the reply anca. Version is opensips-1.4.4-tls, compiled from the
sources with TLS="1". 

----------------------------------------------------------------------

Comment By: Anca Vamanu (anca_vamanu)
Date: 2009-01-28 13:48

Message:
Hi Oren,

What OpenSIPS version are you using? Trunk or stable release?

regards,
Anca

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=2538399&group_id=232389


From noreply at sourceforge.net  Wed Feb 25 17:51:52 2009
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 25 Feb 2009 16:51:52 +0000
Subject: [OpenSIPS-Devel] [ opensips-Bugs-2538399 ] Bug in presence when
	using fallback2db
Message-ID: <E1LcMzA-0005dP-O3@565xhf1.ch3.sourceforge.com>

Bugs item #2538399, was opened at 2009-01-26 14:39
Message generated for change (Comment added) made by oren_k
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=2538399&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: Oren K (oren_k)
Assigned to: Anca Vamanu (anca_vamanu)
Summary: Bug in presence when using fallback2db

Initial Comment:
Hi,

While using the presence module, I run this scenario:

a. user1 SUBSCRIBE's to presence of user2
(subscription is now pending)

b. user2 allows user1 in pres-rules
(refreshWatchers is called, subscription is now active. user1 receives a NOTIFY from presence server with user2's current tuple and Subscription-State: active)

c. user2 PUBLISH'es a new presence tuple
-- at this point presence server should NOTIFY user1 of the new presence but it doesn't (that's the bug).


My modparams:

modparam("presence|presence_xml", "db_url", "mysql://root at localhost/opensips")

modparam("presence", "server_address", "sip:presence.example.com:10500")

modparam("presence", "fallback2db", 1)
modparam("presence", "clean_period", 30)


What I see in the debug trace is that get_subs_dialog (from notify.c) can't find any dialogs in the database, and all those in the subs hash are flagged NO_UPDATEDB_FLAG. This is probably what's causing the problem. 
Strangely, in the above scenario if user1 un-SUBSCRIBEs and re-SUBSCRIBEs to user2's presence - it does receive notifications.

Regards,
Oren K.

----------------------------------------------------------------------

>Comment By: Oren K (oren_k)
Date: 2009-02-25 11:51

Message:
It's fixed!! awesome work, thanks!!

----------------------------------------------------------------------

Comment By: Anca Vamanu (anca_vamanu)
Date: 2009-02-25 11:44

Message:
Hi Oren,

I have tested myself and fixed it. I hope it also works for you. Please
update, test and reply.

regards,
Anca

----------------------------------------------------------------------

Comment By: Oren K (oren_k)
Date: 2009-02-24 09:44

Message:
It would appear that OpenSIPS does not reply in a timely manner:

Feb 23 12:34:58 openims /usr/local/sbin/opensips[3091]:
DBG:tm:utimer_routine: timer routine:4,tl=0xb6183d1c next=(nil),
timeout=974500000
Feb 23 12:35:01 openims opensips-mi-proxy[2368]: [-] error: Error while
processing command refreshWatchers (sip:user2 at openims.summit-tech.ca
presence 0): OpenSIP
S command did timeout

Strangely the first mi_refresh_watchers gets through, this exception only
happens in the second time its called. I'm attaching the logfile from this
run so you can have a look. OpenSIPS does not report any errors, but the
scenario still happens: No NOTIFY is received after user2 PUBLISHes.

----------------------------------------------------------------------

Comment By: Anca Vamanu (anca_vamanu)
Date: 2009-02-24 04:41

Message:
Hi, 

It does not help me if you say what error you get in opensips-mi-proxy. It
would have been better if you said what is the error in opensips :) .
Please look in the log, find the error and print it here.

regards, 
Anca

----------------------------------------------------------------------

Comment By: Oren K (oren_k)
Date: 2009-02-23 12:38

Message:
Thanks for your help Anca. I updated my sources from SVN and recompiled but
unfortunately the bug is still not resolved. I am still getting a crash
from opensips-mi-proxy, its the same one as on my previous comment from
Date: 2009-02-20 13:22

exceptions.ValueError: invalid literal for int() with base 10: 'OpenSIPS'

----------------------------------------------------------------------

Comment By: Anca Vamanu (anca_vamanu)
Date: 2009-02-23 08:57

Message:
Hi Oren,

I have fixed the problem with 'transformations' node. Please update and
test again.

Thanks,
Anca

----------------------------------------------------------------------

Comment By: Oren K (oren_k)
Date: 2009-02-20 13:53

Message:
also I was getting errors because I didn't have a transformations node. The
common-policy schema states that transformations isn't a must-have, and I
think opensips should treat no transformations node the same as if there
was an empty one.

<xs:element name="transformations" type="cp:extensibleType"
minOccurs="0"/>

However, adding a <transformations/> to my pres-rules had not effect on
this bug (still happens).

----------------------------------------------------------------------

Comment By: Oren K (oren_k)
Date: 2009-02-20 13:22

Message:
Something else is wrong now. mi_refresh_watchers is getting a timeout. This
didn't happen before. I'm using:
OpenXCAP 1.0.6
opensips-mi-proxy 1.0.2

Right now nothing works, not even normal scenarios.

Feb 20 13:16:22 openims opensips-mi-proxy[2368]: [-] error: Error while
processing command refreshWatchers (sip:user2 at openims.summit-tech.ca
presence 0): O
penSIPS command did timeout
Feb 20 13:16:22 openims opensips-mi-proxy[2368]: [-] Exception rendering:
Feb 20 13:16:22 openims opensips-mi-proxy[2368]: [-] Traceback (most
recent call last):
Feb 20 13:16:22 openims opensips-mi-proxy[2368]: [-]       File
"/usr/lib/python2.5/site-packages/Twisted-8.2.0_r25964-py2.5-linux-i686.egg/twisted/interne
t/defer.py", line 312, in _startRunCallbacks
Feb 20 13:16:22 openims opensips-mi-proxy[2368]: [-]        
self._runCallbacks()
Feb 20 13:16:22 openims opensips-mi-proxy[2368]: [-]       File
"/usr/lib/python2.5/site-packages/Twisted-8.2.0_r25964-py2.5-linux-i686.egg/twisted/interne
t/defer.py", line 328, in _runCallbacks
Feb 20 13:16:22 openims opensips-mi-proxy[2368]: [-]         self.result =
callback(self.result, *args, **kw)
Feb 20 13:16:22 openims opensips-mi-proxy[2368]: [-]       File
"/usr/lib/python2.5/site-packages/Twisted-8.2.0_r25964-py2.5-linux-i686.egg/twisted/interne
t/defer.py", line 289, in _continue
Feb 20 13:16:22 openims opensips-mi-proxy[2368]: [-]        
self.unpause()
Feb 20 13:16:22 openims opensips-mi-proxy[2368]: [-]       File
"/usr/lib/python2.5/site-packages/Twisted-8.2.0_r25964-py2.5-linux-i686.egg/twisted/interne
t/defer.py", line 285, in unpause
Feb 20 13:16:22 openims opensips-mi-proxy[2368]: [-]        
self._runCallbacks()
Feb 20 13:16:22 openims opensips-mi-proxy[2368]: [-]     --- <exception
caught here> ---
Feb 20 13:16:22 openims opensips-mi-proxy[2368]: [-]       File
"/usr/lib/python2.5/site-packages/Twisted-8.2.0_r25964-py2.5-linux-i686.egg/twisted/interne
t/defer.py", line 328, in _runCallbacks
Feb 20 13:16:22 openims opensips-mi-proxy[2368]: [-]         self.result =
callback(self.result, *args, **kw)
Feb 20 13:16:22 openims opensips-mi-proxy[2368]: [-]       File
"/usr/lib/python2.5/site-packages/miproxy/proxy.py", line 89, in _cbRender
Feb 20 13:16:22 openims opensips-mi-proxy[2368]: [-]         code =
int(code)
Feb 20 13:16:22 openims opensips-mi-proxy[2368]: [-]    
exceptions.ValueError: invalid literal for int() with base 10: 'OpenSIPS'


----------------------------------------------------------------------

Comment By: Anca Vamanu (anca_vamanu)
Date: 2009-02-20 07:59

Message:
Hi,

I have just made a fix. Please update, test again and reply.

Thanks,
Anca

----------------------------------------------------------------------

Comment By: Anca Vamanu (anca_vamanu)
Date: 2009-02-20 07:25

Message:
Hi Oren,

I have looked into the log file that you posted and saw that there was and
error there. There is a problem with the body of the Publish message -
which causes stopping the processing. The problem is that the code in the
presence server expects a tuple element in the body - and the body of the
last Publish message does not contain one.
I have looked up in the RFC and saw that the tuple element is in fact not
compulsory - so there is a bug in the presence code - but not the one you
reported :). 
I will fix this soon.

Thanks and regards,
Anca

----------------------------------------------------------------------

Comment By: Oren K (oren_k)
Date: 2009-02-19 18:42

Message:
Still no joy.. adding updated log and pcap for the version i compiled from
svn 1.5.0dev5-tls.

----------------------------------------------------------------------

Comment By: Anca Vamanu (anca_vamanu)
Date: 2009-02-18 11:11

Message:
Hi, 

I have just now made some changes in presence module for fallback2db case.
Can you please update to the newest svn version for 1.5 and test again?

regards,
Anca

----------------------------------------------------------------------

Comment By: Anca Vamanu (anca_vamanu)
Date: 2009-02-18 11:10

Message:
Hi, 

I have just now made some changes in presence module for fallback2db case.
Can you please update to the newest svn version for 1.5 and test again?

regards,
Anca

----------------------------------------------------------------------

Comment By: Oren K (oren_k)
Date: 2009-02-06 19:23

Message:
Hi Anca,

I've attached a debug-log and wireshark pcap file to the post. The pcap
file also contains the XCAP PUTs to change the presence rules. The only
error in the log comes from presence_xml not being able to extract a tuple
node because our client uses <pdm:person> for the presence (Same bug
happened to us when we tried with <tuple> so that's not the issue). The
things that strike me odd in presence_bug.log are:

(after step b. user2 allows user1 in pres-rules)
line 634: DBG:presence:update_pw_dialogs: found 1 matching dialogs

the module finds the watcher dialog and updates it due to refreshWatchers.
user1 receives a NOTIFY with Subscription-State:active. Now step c. user2
PUBLISH'es a new presence tuple:

line 919: DBG:core:parse_msg:  method:  <PUBLISH>

everything looks okay BUT:

line 1087: DBG:presence:get_subs_db: The query for subscribtion for [uri]=
sip:user2 at openims.summit-tech.ca for [event]= presence returned no result
line 1110: DBG:presence:get_subs_dialog: s->db_flag== UPDATEDB_FLAG
line 1111: DBG:presence:get_subs_dialog: found 0 dialogs( 0 in database
and 0 in hash_table)
line 1112: DBG:presence:publ_notify: Could not find subs_dialog

..suddenly there are no subscribers?

Thanks.


----------------------------------------------------------------------

Comment By: Anca Vamanu (anca_vamanu)
Date: 2009-02-06 13:14

Message:
Hi Oren,

I have just downloaded myself the release and tested and the scenario that
you described works. 
Do you notice any error in your log file?

regards,
Anca

----------------------------------------------------------------------

Comment By: Oren K (oren_k)
Date: 2009-02-01 11:41

Message:
Sorry I forgot to login, that comment is from me :)

----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2009-01-28 10:12

Message:
Thanks for the reply anca. Version is opensips-1.4.4-tls, compiled from the
sources with TLS="1". 

----------------------------------------------------------------------

Comment By: Anca Vamanu (anca_vamanu)
Date: 2009-01-28 06:48

Message:
Hi Oren,

What OpenSIPS version are you using? Trunk or stable release?

regards,
Anca

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=2538399&group_id=232389


From noreply at sourceforge.net  Wed Feb 25 17:52:06 2009
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 25 Feb 2009 16:52:06 +0000
Subject: [OpenSIPS-Devel] [ opensips-Bugs-2538399 ] Bug in presence when
	using fallback2db
Message-ID: <E1LcMzO-0005go-A9@665xhf1.ch3.sourceforge.com>

Bugs item #2538399, was opened at 2009-01-26 14:39
Message generated for change (Settings changed) made by oren_k
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=2538399&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: None
Priority: 5
Private: No
Submitted By: Oren K (oren_k)
Assigned to: Anca Vamanu (anca_vamanu)
Summary: Bug in presence when using fallback2db

Initial Comment:
Hi,

While using the presence module, I run this scenario:

a. user1 SUBSCRIBE's to presence of user2
(subscription is now pending)

b. user2 allows user1 in pres-rules
(refreshWatchers is called, subscription is now active. user1 receives a NOTIFY from presence server with user2's current tuple and Subscription-State: active)

c. user2 PUBLISH'es a new presence tuple
-- at this point presence server should NOTIFY user1 of the new presence but it doesn't (that's the bug).


My modparams:

modparam("presence|presence_xml", "db_url", "mysql://root at localhost/opensips")

modparam("presence", "server_address", "sip:presence.example.com:10500")

modparam("presence", "fallback2db", 1)
modparam("presence", "clean_period", 30)


What I see in the debug trace is that get_subs_dialog (from notify.c) can't find any dialogs in the database, and all those in the subs hash are flagged NO_UPDATEDB_FLAG. This is probably what's causing the problem. 
Strangely, in the above scenario if user1 un-SUBSCRIBEs and re-SUBSCRIBEs to user2's presence - it does receive notifications.

Regards,
Oren K.

----------------------------------------------------------------------

Comment By: Oren K (oren_k)
Date: 2009-02-25 11:51

Message:
It's fixed!! awesome work, thanks!!

----------------------------------------------------------------------

Comment By: Anca Vamanu (anca_vamanu)
Date: 2009-02-25 11:44

Message:
Hi Oren,

I have tested myself and fixed it. I hope it also works for you. Please
update, test and reply.

regards,
Anca

----------------------------------------------------------------------

Comment By: Oren K (oren_k)
Date: 2009-02-24 09:44

Message:
It would appear that OpenSIPS does not reply in a timely manner:

Feb 23 12:34:58 openims /usr/local/sbin/opensips[3091]:
DBG:tm:utimer_routine: timer routine:4,tl=0xb6183d1c next=(nil),
timeout=974500000
Feb 23 12:35:01 openims opensips-mi-proxy[2368]: [-] error: Error while
processing command refreshWatchers (sip:user2 at openims.summit-tech.ca
presence 0): OpenSIP
S command did timeout

Strangely the first mi_refresh_watchers gets through, this exception only
happens in the second time its called. I'm attaching the logfile from this
run so you can have a look. OpenSIPS does not report any errors, but the
scenario still happens: No NOTIFY is received after user2 PUBLISHes.

----------------------------------------------------------------------

Comment By: Anca Vamanu (anca_vamanu)
Date: 2009-02-24 04:41

Message:
Hi, 

It does not help me if you say what error you get in opensips-mi-proxy. It
would have been better if you said what is the error in opensips :) .
Please look in the log, find the error and print it here.

regards, 
Anca

----------------------------------------------------------------------

Comment By: Oren K (oren_k)
Date: 2009-02-23 12:38

Message:
Thanks for your help Anca. I updated my sources from SVN and recompiled but
unfortunately the bug is still not resolved. I am still getting a crash
from opensips-mi-proxy, its the same one as on my previous comment from
Date: 2009-02-20 13:22

exceptions.ValueError: invalid literal for int() with base 10: 'OpenSIPS'

----------------------------------------------------------------------

Comment By: Anca Vamanu (anca_vamanu)
Date: 2009-02-23 08:57

Message:
Hi Oren,

I have fixed the problem with 'transformations' node. Please update and
test again.

Thanks,
Anca

----------------------------------------------------------------------

Comment By: Oren K (oren_k)
Date: 2009-02-20 13:53

Message:
also I was getting errors because I didn't have a transformations node. The
common-policy schema states that transformations isn't a must-have, and I
think opensips should treat no transformations node the same as if there
was an empty one.

<xs:element name="transformations" type="cp:extensibleType"
minOccurs="0"/>

However, adding a <transformations/> to my pres-rules had not effect on
this bug (still happens).

----------------------------------------------------------------------

Comment By: Oren K (oren_k)
Date: 2009-02-20 13:22

Message:
Something else is wrong now. mi_refresh_watchers is getting a timeout. This
didn't happen before. I'm using:
OpenXCAP 1.0.6
opensips-mi-proxy 1.0.2

Right now nothing works, not even normal scenarios.

Feb 20 13:16:22 openims opensips-mi-proxy[2368]: [-] error: Error while
processing command refreshWatchers (sip:user2 at openims.summit-tech.ca
presence 0): O
penSIPS command did timeout
Feb 20 13:16:22 openims opensips-mi-proxy[2368]: [-] Exception rendering:
Feb 20 13:16:22 openims opensips-mi-proxy[2368]: [-] Traceback (most
recent call last):
Feb 20 13:16:22 openims opensips-mi-proxy[2368]: [-]       File
"/usr/lib/python2.5/site-packages/Twisted-8.2.0_r25964-py2.5-linux-i686.egg/twisted/interne
t/defer.py", line 312, in _startRunCallbacks
Feb 20 13:16:22 openims opensips-mi-proxy[2368]: [-]        
self._runCallbacks()
Feb 20 13:16:22 openims opensips-mi-proxy[2368]: [-]       File
"/usr/lib/python2.5/site-packages/Twisted-8.2.0_r25964-py2.5-linux-i686.egg/twisted/interne
t/defer.py", line 328, in _runCallbacks
Feb 20 13:16:22 openims opensips-mi-proxy[2368]: [-]         self.result =
callback(self.result, *args, **kw)
Feb 20 13:16:22 openims opensips-mi-proxy[2368]: [-]       File
"/usr/lib/python2.5/site-packages/Twisted-8.2.0_r25964-py2.5-linux-i686.egg/twisted/interne
t/defer.py", line 289, in _continue
Feb 20 13:16:22 openims opensips-mi-proxy[2368]: [-]        
self.unpause()
Feb 20 13:16:22 openims opensips-mi-proxy[2368]: [-]       File
"/usr/lib/python2.5/site-packages/Twisted-8.2.0_r25964-py2.5-linux-i686.egg/twisted/interne
t/defer.py", line 285, in unpause
Feb 20 13:16:22 openims opensips-mi-proxy[2368]: [-]        
self._runCallbacks()
Feb 20 13:16:22 openims opensips-mi-proxy[2368]: [-]     --- <exception
caught here> ---
Feb 20 13:16:22 openims opensips-mi-proxy[2368]: [-]       File
"/usr/lib/python2.5/site-packages/Twisted-8.2.0_r25964-py2.5-linux-i686.egg/twisted/interne
t/defer.py", line 328, in _runCallbacks
Feb 20 13:16:22 openims opensips-mi-proxy[2368]: [-]         self.result =
callback(self.result, *args, **kw)
Feb 20 13:16:22 openims opensips-mi-proxy[2368]: [-]       File
"/usr/lib/python2.5/site-packages/miproxy/proxy.py", line 89, in _cbRender
Feb 20 13:16:22 openims opensips-mi-proxy[2368]: [-]         code =
int(code)
Feb 20 13:16:22 openims opensips-mi-proxy[2368]: [-]    
exceptions.ValueError: invalid literal for int() with base 10: 'OpenSIPS'


----------------------------------------------------------------------

Comment By: Anca Vamanu (anca_vamanu)
Date: 2009-02-20 07:59

Message:
Hi,

I have just made a fix. Please update, test again and reply.

Thanks,
Anca

----------------------------------------------------------------------

Comment By: Anca Vamanu (anca_vamanu)
Date: 2009-02-20 07:25

Message:
Hi Oren,

I have looked into the log file that you posted and saw that there was and
error there. There is a problem with the body of the Publish message -
which causes stopping the processing. The problem is that the code in the
presence server expects a tuple element in the body - and the body of the
last Publish message does not contain one.
I have looked up in the RFC and saw that the tuple element is in fact not
compulsory - so there is a bug in the presence code - but not the one you
reported :). 
I will fix this soon.

Thanks and regards,
Anca

----------------------------------------------------------------------

Comment By: Oren K (oren_k)
Date: 2009-02-19 18:42

Message:
Still no joy.. adding updated log and pcap for the version i compiled from
svn 1.5.0dev5-tls.

----------------------------------------------------------------------

Comment By: Anca Vamanu (anca_vamanu)
Date: 2009-02-18 11:11

Message:
Hi, 

I have just now made some changes in presence module for fallback2db case.
Can you please update to the newest svn version for 1.5 and test again?

regards,
Anca

----------------------------------------------------------------------

Comment By: Anca Vamanu (anca_vamanu)
Date: 2009-02-18 11:10

Message:
Hi, 

I have just now made some changes in presence module for fallback2db case.
Can you please update to the newest svn version for 1.5 and test again?

regards,
Anca

----------------------------------------------------------------------

Comment By: Oren K (oren_k)
Date: 2009-02-06 19:23

Message:
Hi Anca,

I've attached a debug-log and wireshark pcap file to the post. The pcap
file also contains the XCAP PUTs to change the presence rules. The only
error in the log comes from presence_xml not being able to extract a tuple
node because our client uses <pdm:person> for the presence (Same bug
happened to us when we tried with <tuple> so that's not the issue). The
things that strike me odd in presence_bug.log are:

(after step b. user2 allows user1 in pres-rules)
line 634: DBG:presence:update_pw_dialogs: found 1 matching dialogs

the module finds the watcher dialog and updates it due to refreshWatchers.
user1 receives a NOTIFY with Subscription-State:active. Now step c. user2
PUBLISH'es a new presence tuple:

line 919: DBG:core:parse_msg:  method:  <PUBLISH>

everything looks okay BUT:

line 1087: DBG:presence:get_subs_db: The query for subscribtion for [uri]=
sip:user2 at openims.summit-tech.ca for [event]= presence returned no result
line 1110: DBG:presence:get_subs_dialog: s->db_flag== UPDATEDB_FLAG
line 1111: DBG:presence:get_subs_dialog: found 0 dialogs( 0 in database
and 0 in hash_table)
line 1112: DBG:presence:publ_notify: Could not find subs_dialog

..suddenly there are no subscribers?

Thanks.


----------------------------------------------------------------------

Comment By: Anca Vamanu (anca_vamanu)
Date: 2009-02-06 13:14

Message:
Hi Oren,

I have just downloaded myself the release and tested and the scenario that
you described works. 
Do you notice any error in your log file?

regards,
Anca

----------------------------------------------------------------------

Comment By: Oren K (oren_k)
Date: 2009-02-01 11:41

Message:
Sorry I forgot to login, that comment is from me :)

----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2009-01-28 10:12

Message:
Thanks for the reply anca. Version is opensips-1.4.4-tls, compiled from the
sources with TLS="1". 

----------------------------------------------------------------------

Comment By: Anca Vamanu (anca_vamanu)
Date: 2009-01-28 06:48

Message:
Hi Oren,

What OpenSIPS version are you using? Trunk or stable release?

regards,
Anca

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=2538399&group_id=232389


From noreply at sourceforge.net  Wed Feb 25 19:06:20 2009
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 25 Feb 2009 18:06:20 +0000
Subject: [OpenSIPS-Devel] [ opensips-Bugs-2636710 ] rr (loose_route) should
	take aliases from domain module
Message-ID: <E1LcO9E-0004q2-Dd@3bkjzd1.ch3.sourceforge.com>

Bugs item #2636710, was opened at 2009-02-25 14:14
Message generated for change (Settings changed) made by bogdan_iancu
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=2636710&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: Accepted
>Priority: 6
Private: No
Submitted By: Thomas Gelf (thomas_gelf)
>Assigned to: Bogdan-Andrei Iancu (bogdan_iancu)
Summary: rr (loose_route) should take aliases from domain module

Initial Comment:
OpenSIPS 1.5 (SVN, today) still needs aliases to be defined manually using alias=... - otherwise loose_route() doesn't detect them as "local", even if defined in the domain table.

Best regards,
Thomas Gelf


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=2636710&group_id=232389


From noreply at sourceforge.net  Wed Feb 25 22:26:06 2009
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 25 Feb 2009 21:26:06 +0000
Subject: [OpenSIPS-Devel] [ opensips-Bugs-2638551 ] trace_dialog fails
Message-ID: <E1LcRGY-0004yY-NC@b55xhf1.ch3.sourceforge.com>

Bugs item #2638551, was opened at 2009-02-25 21:26
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=2638551&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: Norm Brandinger (norm_brandinger)
Assigned to: Nobody/Anonymous (nobody)
Summary: trace_dialog fails

Initial Comment:
The trace_dialog() function fails because the logic in the dialog module that extracts the cseq value is bad.

The attached patch correct the problem.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=2638551&group_id=232389


From noreply at sourceforge.net  Wed Feb 25 22:46:01 2009
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 25 Feb 2009 21:46:01 +0000
Subject: [OpenSIPS-Devel] [ opensips-Bugs-2638630 ] Compiling trunk requires
	libxml
Message-ID: <E1LcRZp-0006Zm-0S@1bkjzd1.ch3.sourceforge.com>

Bugs item #2638630, was opened at 2009-02-25 22:46
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=2638630&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: Sebastian Schumann (s_schumann)
Assigned to: Nobody/Anonymous (nobody)
Summary: Compiling trunk requires libxml

Initial Comment:
Hi

If I compile the trunk, it does not compile without libxml. 

That should be fixed: pua_dialoginfo and presence_dialoginfo should be excluded by default as well (from Makefile exclude_modules).

Best regards
Sebastian

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=2638630&group_id=232389


From noreply at sourceforge.net  Thu Feb 26 09:59:36 2009
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 26 Feb 2009 08:59:36 +0000
Subject: [OpenSIPS-Devel] [ opensips-Bugs-2638630 ] Compiling trunk requires
	libxml
Message-ID: <E1Lcc5g-0001on-Fg@565xhf1.ch3.sourceforge.com>

Bugs item #2638630, was opened at 2009-02-25 23:46
Message generated for change (Settings changed) made by bogdan_iancu
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=2638630&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: Accepted
Priority: 5
Private: No
Submitted By: Sebastian Schumann (s_schumann)
>Assigned to: Bogdan-Andrei Iancu (bogdan_iancu)
Summary: Compiling trunk requires libxml

Initial Comment:
Hi

If I compile the trunk, it does not compile without libxml. 

That should be fixed: pua_dialoginfo and presence_dialoginfo should be excluded by default as well (from Makefile exclude_modules).

Best regards
Sebastian

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=2638630&group_id=232389


From noreply at sourceforge.net  Thu Feb 26 10:01:13 2009
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 26 Feb 2009 09:01:13 +0000
Subject: [OpenSIPS-Devel] [ opensips-Bugs-2638551 ] trace_dialog fails
Message-ID: <E1Lcc7F-00052l-47@1bkjzd1.ch3.sourceforge.com>

Bugs item #2638551, was opened at 2009-02-25 23: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=2638551&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: trunk
Status: Open
>Resolution: Accepted
Priority: 5
Private: No
Submitted By: Norm Brandinger (norm_brandinger)
>Assigned to: Bogdan-Andrei Iancu (bogdan_iancu)
Summary: trace_dialog fails

Initial Comment:
The trace_dialog() function fails because the logic in the dialog module that extracts the cseq value is bad.

The attached patch correct the problem.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=2638551&group_id=232389


From bogdan at voice-system.ro  Thu Feb 26 10:07:48 2009
From: bogdan at voice-system.ro (Bogdan-Andrei Iancu)
Date: Thu, 26 Feb 2009 09:07:48 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[5361] trunk/Makefile.defs
Message-ID: <E1LccDc-0002ep-16@d5vjzd1.ch3.sourceforge.com>

Revision: 5361
          http://opensips.svn.sourceforge.net/opensips/?rev=5361&view=rev
Author:   bogdan_iancu
Date:     2009-02-26 09:07:47 +0000 (Thu, 26 Feb 2009)

Log Message:
-----------
- exclude from default compiling modules with libcml2 deps (pua_dialoginfo and presence_dialoginfo).

Closes #2638630.
Credits go to Sebastian Schumann

Modified Paths:
--------------
    trunk/Makefile.defs


This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site.


From noreply at sourceforge.net  Thu Feb 26 10:08:04 2009
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 26 Feb 2009 09:08:04 +0000
Subject: [OpenSIPS-Devel] [ opensips-Bugs-2638630 ] Compiling trunk requires
	libxml
Message-ID: <E1LccDs-00089V-1e@155xhf1.ch3.sourceforge.com>

Bugs item #2638630, was opened at 2009-02-25 23:46
Message generated for change (Settings changed) made by bogdan_iancu
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=2638630&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: Sebastian Schumann (s_schumann)
Assigned to: Bogdan-Andrei Iancu (bogdan_iancu)
Summary: Compiling trunk requires libxml

Initial Comment:
Hi

If I compile the trunk, it does not compile without libxml. 

That should be fixed: pua_dialoginfo and presence_dialoginfo should be excluded by default as well (from Makefile exclude_modules).

Best regards
Sebastian

----------------------------------------------------------------------

>Comment By: Bogdan-Andrei Iancu (bogdan_iancu)
Date: 2009-02-26 11:08

Message:
Thanks Sebastian! It is now fixed on SVN

Regards,
Bogdan

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=2638630&group_id=232389


From bogdan at voice-system.ro  Thu Feb 26 10:09:33 2009
From: bogdan at voice-system.ro (Bogdan-Andrei Iancu)
Date: Thu, 26 Feb 2009 09:09:33 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[5362]
	trunk/modules/dialog/dlg_handlers.c
Message-ID: <E1LccFJ-0002gX-VY@d5vjzd1.ch3.sourceforge.com>

Revision: 5362
          http://opensips.svn.sourceforge.net/opensips/?rev=5362&view=rev
Author:   bogdan_iancu
Date:     2009-02-26 09:09:33 +0000 (Thu, 26 Feb 2009)

Log Message:
-----------
- fixed detection and parsing of CSEQ header.

Closes #2638551.
Credits go to Norm Brandinger.

Modified Paths:
--------------
    trunk/modules/dialog/dlg_handlers.c


This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site.


From bogdan at voice-system.ro  Thu Feb 26 10:12:00 2009
From: bogdan at voice-system.ro (Bogdan-Andrei Iancu)
Date: Thu, 26 Feb 2009 09:12:00 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[5363]
	branches/1.4/modules/dialog/dlg_handlers.c
Message-ID: <E1LccHg-0002il-Gs@d5vjzd1.ch3.sourceforge.com>

Revision: 5363
          http://opensips.svn.sourceforge.net/opensips/?rev=5363&view=rev
Author:   bogdan_iancu
Date:     2009-02-26 09:12:00 +0000 (Thu, 26 Feb 2009)

Log Message:
-----------
backport from trunk (rev #5362):

- fixed detection and parsing of CSEQ header.

Closes #2638551.
Credits go to Norm Brandinger.

Revision Links:
--------------
    http://opensips.svn.sourceforge.net/opensips/?rev=5362&view=rev

Modified Paths:
--------------
    branches/1.4/modules/dialog/dlg_handlers.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 Feb 26 10:12:25 2009
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 26 Feb 2009 09:12:25 +0000
Subject: [OpenSIPS-Devel] [ opensips-Bugs-2638551 ] trace_dialog fails
Message-ID: <E1LccI5-0003up-R5@d45xhf1.ch3.sourceforge.com>

Bugs item #2638551, was opened at 2009-02-25 23: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=2638551&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: trunk
>Status: Closed
>Resolution: Fixed
Priority: 5
Private: No
Submitted By: Norm Brandinger (norm_brandinger)
Assigned to: Bogdan-Andrei Iancu (bogdan_iancu)
Summary: trace_dialog fails

Initial Comment:
The trace_dialog() function fails because the logic in the dialog module that extracts the cseq value is bad.

The attached patch correct the problem.


----------------------------------------------------------------------

>Comment By: Bogdan-Andrei Iancu (bogdan_iancu)
Date: 2009-02-26 11:12

Message:
Thanks Norm,

I applied the patch on 1.4 and 1.5 versions.

Regards,
bogdan

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=2638551&group_id=232389


From bogdan at voice-system.ro  Thu Feb 26 10:37:07 2009
From: bogdan at voice-system.ro (Bogdan-Andrei Iancu)
Date: Thu, 26 Feb 2009 09:37:07 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[5364]
	trunk/modules/dialog/dlg_db_handler.c
Message-ID: <E1Lccfz-0003bD-JZ@d5vjzd1.ch3.sourceforge.com>

Revision: 5364
          http://opensips.svn.sourceforge.net/opensips/?rev=5364&view=rev
Author:   bogdan_iancu
Date:     2009-02-26 09:37:07 +0000 (Thu, 26 Feb 2009)

Log Message:
-----------
- fixed crash when trying to save in DB the callee socket (that might be null).

Closes bug #2633350.
Credits go to Vasil Kolev.

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 bogdan at voice-system.ro  Thu Feb 26 10:43:32 2009
From: bogdan at voice-system.ro (Bogdan-Andrei Iancu)
Date: Thu, 26 Feb 2009 09:43:32 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[5365]
	trunk/modules/dialog/dlg_db_handler.c
Message-ID: <E1LccmC-0003i9-6M@d5vjzd1.ch3.sourceforge.com>

Revision: 5365
          http://opensips.svn.sourceforge.net/opensips/?rev=5365&view=rev
Author:   bogdan_iancu
Date:     2009-02-26 09:43:31 +0000 (Thu, 26 Feb 2009)

Log Message:
-----------
- completion to the previous fix - another place where the callee socket (which may be NULL) is saved in DB.

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 bogdan at voice-system.ro  Thu Feb 26 10:47:00 2009
From: bogdan at voice-system.ro (Bogdan-Andrei Iancu)
Date: Thu, 26 Feb 2009 09:47:00 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[5366]
	branches/1.4/modules/dialog/dlg_db_handler.c
Message-ID: <E1LccpY-0003mY-Jj@d5vjzd1.ch3.sourceforge.com>

Revision: 5366
          http://opensips.svn.sourceforge.net/opensips/?rev=5366&view=rev
Author:   bogdan_iancu
Date:     2009-02-26 09:47:00 +0000 (Thu, 26 Feb 2009)

Log Message:
-----------
backport from trunk (rev #5365 + #5365):
- fixed crash when trying to save in DB the callee socket (that might be null).

Closes bug #2633350.
Credits go to Vasil Kolev.

- completion to the previous fix - another place where the callee socket (which may be NULL) is saved in DB.

Revision Links:
--------------
    http://opensips.svn.sourceforge.net/opensips/?rev=5365&view=rev

Modified Paths:
--------------
    branches/1.4/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  Thu Feb 26 10:47:56 2009
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 26 Feb 2009 09:47:56 +0000
Subject: [OpenSIPS-Devel] [ opensips-Bugs-2633350 ] Crash in dialog
	module+patch
Message-ID: <E1LccqS-0002Dy-5g@g45xhf1.ch3.sourceforge.com>

Bugs item #2633350, was opened at 2009-02-24 14: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=2633350&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: 9
Private: No
Submitted By: Vasil Kolev (krokodilerian)
Assigned to: Bogdan-Andrei Iancu (bogdan_iancu)
Summary: Crash in dialog module+patch

Initial Comment:
When using the dialog module with realtime db usage, it crashes with the following backtrace:

(gdb) bt
#0  0xb77f9104 in update_dialog_dbinfo (cell=0xb57ba410) at dlg_db_handler.c:511
#1  0xb7800370 in dlg_onreply (t=0xb57b0db8, type=128, param=0xb78c1b34) at dlg_handlers.c:323
#2  0xb789d22b in run_trans_callbacks (type=128, trans=0xb57b0db8, req=0xb57bb6f0, rpl=0xffffffff, code=200) at t_hooks.c:208
#3  0xb78b2cf3 in _reply_light (trans=0xb57b0db8, 
    buf=0x819f428 "SIP/2.0 200 OK\r\nVia: SIP/2.0/UDP 89.253.129.130:27819;branch=z9hG4bK-d8754z-cb4ec1c38ba46444-1---d8754z-;rport=27819\r\nTo: <sip:vasil.kolev%40securax.org at sip.zoiper.com;transport=UDP>;tag=945b7285134e5"..., len=<value optimized out>, code=200, to_tag=0xb78d2a40 "945b7285134e5709ca8a0d8ffb065070-ab6d", to_tag_len=37, lock=1, bm=0xbfd0106c) at t_reply.c:373
#4  0xb78b3425 in _reply (trans=0xb57b0db8, p_msg=<value optimized out>, code=200, text=0xb77a4b08, lock=1) at t_reply.c:446
#5  0xb78a75ba in w_t_reply (msg=0x819dfb0, str1=0xc8 <Address 0xc8 out of bounds>, str2=0xb77a4b08 ">\az?\002") at tm.c:863
#6  0xb7d5beba in sig_send_reply_mod (msg=0x819dfb0, code=200, reason=0xb77a4b08, to_tag=0xbfd012f8) at signaling.c:178
#7  0xb779708a in send_2XX_reply (msg=0x819dfb0, reply_code=200, lexpire=<value optimized out>, rtag=0xbfd012f8, local_contact=0xbfd01324) at subscribe.c:112
#8  0xb7797d72 in update_subscription (msg=0x819dfb0, subs=0xbfd012c4, init_req=1) at subscribe.c:378
#9  0xb779c72b in handle_subscribe (msg=0x819dfb0, str1=0x0, str2=0x0) at subscribe.c:699
#10 0x08055591 in do_action (a=0x8196618, msg=0x819dfb0) at action.c:961
#11 0x080541e2 in run_action_list (a=0x8196618, msg=0x819dfb0) at action.c:139
#12 0x08056ecd in do_action (a=0x8197550, msg=0x819dfb0) at action.c:705
#13 0x080541e2 in run_action_list (a=0x8197550, msg=0x819dfb0) at action.c:139
#14 0x08057529 in do_action (a=0x81975b8, msg=0x819dfb0) at action.c:711
#15 0x080541e2 in run_action_list (a=0x81960a8, msg=0x819dfb0) at action.c:139
#16 0x08056914 in do_action (a=0x81934e0, msg=0x819dfb0) at action.c:119
#17 0x080541e2 in run_action_list (a=0x81934e0, msg=0x819dfb0) at action.c:139
#18 0x08056ecd in do_action (a=0x8193548, msg=0x819dfb0) at action.c:705
#19 0x080541e2 in run_action_list (a=0x818e390, msg=0x819dfb0) at action.c:139
#20 0x08057ee1 in run_top_route (a=0x818e390, msg=0x819dfb0) at action.c:119
#21 0x0809228c in receive_msg (
    buf=0x8164220 "SUBSCRIBE sip:vasil.kolev%40securax.org at sip.zoiper.com;transport=UDP SIP/2.0\r\nVia: SIP/2.0/UDP 89.253.129.130:27819;branch=z9hG4bK-d8754z-cb4ec1c38ba46444-1---d8754z-;rport\r\nMax-Forwards: 69\r\nContact:"..., len=933, rcv_info=0xbfd020a4) at receive.c:165
#22 0x080cdf4b in udp_rcv_loop () at udp_server.c:449
#23 0x0806c3af in main (argc=1, argv=0xbfd02234) at main.c:778


When investigating it, turned out that cell->bind_addr[DLG_CALLEE_LEG] is NULL, and while trying to dereference that to get the sock_str, it crashes. I added a check and a specific str null_element to update it right.

Also, there was a strange typo in the LM_DBG there, it was using the value from the cell->bind_addr[DLG_CALLEE_LEG]->sock_str, but the length from cell->bind_addr[DLG_CALLER_LEG]->sock_str.

Patch attached (against trunk).

----------------------------------------------------------------------

>Comment By: Bogdan-Andrei Iancu (bogdan_iancu)
Date: 2009-02-26 11:47

Message:
Hi Vasil,

I commited the fix (1.4 + 1.5 versions)- the same fix had to be applied in
a similar other place.

Thanks & Regards,
Bogdan


----------------------------------------------------------------------

Comment By: Bogdan-Andrei Iancu (bogdan_iancu)
Date: 2009-02-24 16:39

Message:
Hi Vasil,

it seams like a bug - I will review the patch and apply it asap.

Thanks and regards,
Bogdan

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=2633350&group_id=232389


From bogdan at voice-system.ro  Thu Feb 26 10:59:15 2009
From: bogdan at voice-system.ro (Bogdan-Andrei Iancu)
Date: Thu, 26 Feb 2009 09:59:15 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[5367] trunk/name_alias.h
Message-ID: <E1Lcd1P-0003wY-Tz@d5vjzd1.ch3.sourceforge.com>

Revision: 5367
          http://opensips.svn.sourceforge.net/opensips/?rev=5367&view=rev
Author:   bogdan_iancu
Date:     2009-02-26 09:59:15 +0000 (Thu, 26 Feb 2009)

Log Message:
-----------
- fixed bug in unproper call of the registered functions for detecting the aliases.
  Closes 2636710.
  Reported by Thomas Gelf.

Modified Paths:
--------------
    trunk/name_alias.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 Feb 26 11:00:26 2009
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 26 Feb 2009 10:00:26 +0000
Subject: [OpenSIPS-Devel] [ opensips-Bugs-2636710 ] rr (loose_route) should
	take aliases from domain module
Message-ID: <E1Lcd2Y-0003LU-Mb@cdv4jf1.ch3.sourceforge.com>

Bugs item #2636710, was opened at 2009-02-25 14:14
Message generated for change (Comment added) made by bogdan_iancu
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=2636710&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: 6
Private: No
Submitted By: Thomas Gelf (thomas_gelf)
Assigned to: Bogdan-Andrei Iancu (bogdan_iancu)
Summary: rr (loose_route) should take aliases from domain module

Initial Comment:
OpenSIPS 1.5 (SVN, today) still needs aliases to be defined manually using alias=... - otherwise loose_route() doesn't detect them as "local", even if defined in the domain table.

Best regards,
Thomas Gelf


----------------------------------------------------------------------

>Comment By: Bogdan-Andrei Iancu (bogdan_iancu)
Date: 2009-02-26 12:00

Message:
Hi Thomas,

A fix in available on SVN - please update and give it one more try. As per
discussion on the IRC channel, for testing, remove the aliase="" from your
cfg file.

Regards,
Bogdan

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=2636710&group_id=232389


From bogdan at voice-system.ro  Thu Feb 26 11:17:03 2009
From: bogdan at voice-system.ro (Bogdan-Andrei Iancu)
Date: Thu, 26 Feb 2009 10:17:03 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[5368]
	trunk/modules/db_postgres/res.c
Message-ID: <E1LcdId-0004H0-B2@d5vjzd1.ch3.sourceforge.com>

Revision: 5368
          http://opensips.svn.sourceforge.net/opensips/?rev=5368&view=rev
Author:   bogdan_iancu
Date:     2009-02-26 10:17:03 +0000 (Thu, 26 Feb 2009)

Log Message:
-----------
- fixed bad parsing of returned BLOBs.

Closes bug #2636665.
Credita go to Vasil Kolev.

Modified Paths:
--------------
    trunk/modules/db_postgres/res.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 Feb 26 11:18:30 2009
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 26 Feb 2009 10:18:30 +0000
Subject: [OpenSIPS-Devel] [ opensips-Bugs-2636665 ] Bad parsing of BLOBs in
	db_postgres+patch
Message-ID: <E1LcdK2-0000K2-Tf@d45xhf1.ch3.sourceforge.com>

Bugs item #2636665, was opened at 2009-02-25 13:53
Message generated for change (Comment added) made by bogdan_iancu
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=2636665&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: Vasil Kolev (krokodilerian)
>Assigned to: Bogdan-Andrei Iancu (bogdan_iancu)
Summary: Bad parsing of BLOBs in db_postgres+patch

Initial Comment:
Excerpt from the logs:

Feb 25 11:09:20 [12106] DBG:db_postgres:db_postgres_submit_query: 0x8198488 PQsendQuery(select presentity_uri,expires,event,event_id,to_user,to_domain,watcher_username,watcher_domain,callid,to_tag,from_tag
,local_cseq,remote_cseq,record_route,socket_info,contact,local_contact,version,status,reason from active_watchers )
Feb 25 11:09:20 [12106] DBG:core:db_new_result: allocate 28 bytes for result set at 0x81984e8
Feb 25 11:09:20 [12106] DBG:db_postgres:db_postgres_fetch_result: 0x8198488 PQresultStatus(PGRES_TUPLES_OK) PQgetResult(0x9807030)
Feb 25 11:09:20 [12106] DBG:db_postgres:db_postgres_get_columns: 20 columns returned from the query
Feb 25 11:09:20 [12106] DBG:core:db_allocate_columns: allocate 320 bytes for result columns at 0x8198ae8
...
...
...
Feb 25 11:09:20 [12106] DBG:db_postgres:db_postgres_get_columns: RES_NAMES(0x8198bf0)[13]=[record_route]
Feb 25 11:09:20 [12106] DBG:db_postgres:db_postgres_get_columns: use DB_BLOB result type
...
...
...
Feb 25 11:09:20 [12106] DBG:db_postgres:db_postgres_convert_rows: allocated 0 bytes for row_buf[13] at 0x8198c88
Feb 25 11:09:20 [12106] DBG:db_postgres:db_postgres_convert_rows: [0][13] Column[record_route]=[]
...
...
...
Feb 25 11:09:20 [12106] DBG:db_postgres:db_postgres_str2val: converting BLOB []
Feb 25 11:09:20 [12106] DBG:db_postgres:db_postgres_str2val: got blob len 0
...
...
...
Feb 25 11:09:20 [12106] DBG:db_postgres:db_postgres_convert_rows: PQgetvalue(0x8198488,1,13)=[<98>!<F7><B7><98>!<F7><B7>^P]
Feb 25 11:09:20 [12106] DBG:db_postgres:db_postgres_convert_rows: allocated 9 bytes for row_buf[13] at 0x819a7a8

Patch should be self-explanatory :)

----------------------------------------------------------------------

>Comment By: Bogdan-Andrei Iancu (bogdan_iancu)
Date: 2009-02-26 12:18

Message:
Hi Vasil,

I applied the patch on SVN (1.4 and 1.5 vers), but slightly modified -
please update from SVN and test it - I want to be sure I haven't screwed up
something :).

Thanks and regards,
Bogdan

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=2636665&group_id=232389


From bogdan at voice-system.ro  Thu Feb 26 11:19:50 2009
From: bogdan at voice-system.ro (Bogdan-Andrei Iancu)
Date: Thu, 26 Feb 2009 10:19:50 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[5369]
	branches/1.4/modules/db_postgres/res.c
Message-ID: <E1LcdLK-0004Iz-7N@d5vjzd1.ch3.sourceforge.com>

Revision: 5369
          http://opensips.svn.sourceforge.net/opensips/?rev=5369&view=rev
Author:   bogdan_iancu
Date:     2009-02-26 10:19:50 +0000 (Thu, 26 Feb 2009)

Log Message:
-----------
backport from trunk (rev 5368):
- fixed bad parsing of returned BLOBs.

Closes bug #2636665.
Credita go to Vasil Kolev.

Revision Links:
--------------
    http://opensips.svn.sourceforge.net/opensips/?rev=5368&view=rev

Modified Paths:
--------------
    branches/1.4/modules/db_postgres/res.c


This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site.


From bogdan at voice-system.ro  Thu Feb 26 11:59:09 2009
From: bogdan at voice-system.ro (Bogdan-Andrei Iancu)
Date: Thu, 26 Feb 2009 10:59:09 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[5370]
	trunk/modules/auth_radius/sterman.c
Message-ID: <E1LcdxN-0005OT-1z@d5vjzd1.ch3.sourceforge.com>

Revision: 5370
          http://opensips.svn.sourceforge.net/opensips/?rev=5370&view=rev
Author:   bogdan_iancu
Date:     2009-02-26 10:59:06 +0000 (Thu, 26 Feb 2009)

Log Message:
-----------
-fixed fetching of returned AVPS in RADIUS reply.
 
 Closes bug #2627561
 Credits go to Alex Massover.

Modified Paths:
--------------
    trunk/modules/auth_radius/sterman.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 Feb 26 12:00:30 2009
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 26 Feb 2009 11:00:30 +0000
Subject: [OpenSIPS-Devel] [ opensips-Bugs-2627561 ] auth_radius: allow
	sip-avps to be passed for rejected reques
Message-ID: <E1Lcdyg-00083i-8T@155xhf1.ch3.sourceforge.com>

Bugs item #2627561, was opened at 2009-02-22 14:09
Message generated for change (Comment added) made by bogdan_iancu
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=2627561&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: Alex Massover (cupotka2008)
Assigned to: Bogdan-Andrei Iancu (bogdan_iancu)
Summary: auth_radius: allow sip-avps to be passed for rejected reques

Initial Comment:
Hi!

This simple patch for auth_radius module allows to pass additional credentials (sip-avps) also for rejected radius requests. For example it can be used for passing custom error codes.

Best Regards,
Alex Massover.

----------------------------------------------------------------------

>Comment By: Bogdan-Andrei Iancu (bogdan_iancu)
Date: 2009-02-26 13:00

Message:
Alex,

I applied the patch on 1.5 - I did some small change to try to get the AVP
from a the RADIUS reply (if valid) disregarding the reply code. Could you
please overview and confirm if ok?

I'm waiting for your confirmation before backporting to 1.4

Regards,
Bogdan

----------------------------------------------------------------------

Comment By: Bogdan-Andrei Iancu (bogdan_iancu)
Date: 2009-02-24 16:36

Message:
Hi Alex,

Thanks - this is more like a bug, so I moved it accordingly. I will
shortly overview and commit it.

Regards,
Bogdan

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=2627561&group_id=232389


From noreply at sourceforge.net  Thu Feb 26 12:17:46 2009
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 26 Feb 2009 11:17:46 +0000
Subject: [OpenSIPS-Devel] [ opensips-Bugs-2627561 ] auth_radius: allow
	sip-avps to be passed for rejected reques
Message-ID: <E1LceFO-0008Es-Bx@b55xhf1.ch3.sourceforge.com>

Bugs item #2627561, was opened at 2009-02-22 12:09
Message generated for change (Comment added) made by nobody
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=2627561&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: Alex Massover (cupotka2008)
Assigned to: Bogdan-Andrei Iancu (bogdan_iancu)
Summary: auth_radius: allow sip-avps to be passed for rejected reques

Initial Comment:
Hi!

This simple patch for auth_radius module allows to pass additional credentials (sip-avps) also for rejected radius requests. For example it can be used for passing custom error codes.

Best Regards,
Alex Massover.

----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2009-02-26 11:17

Message:
Hi!

The following one is working for me for 1.3.2. I'm starting migration to
1.5, and will test it also.

} else {
                LM_ERR("rc_auth failed\n");
                if (received) generate_avps(received);
                goto err;
        }


----------------------------------------------------------------------

Comment By: Bogdan-Andrei Iancu (bogdan_iancu)
Date: 2009-02-26 11:00

Message:
Alex,

I applied the patch on 1.5 - I did some small change to try to get the AVP
from a the RADIUS reply (if valid) disregarding the reply code. Could you
please overview and confirm if ok?

I'm waiting for your confirmation before backporting to 1.4

Regards,
Bogdan

----------------------------------------------------------------------

Comment By: Bogdan-Andrei Iancu (bogdan_iancu)
Date: 2009-02-24 14:36

Message:
Hi Alex,

Thanks - this is more like a bug, so I moved it accordingly. I will
shortly overview and commit it.

Regards,
Bogdan

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=2627561&group_id=232389


From noreply at sourceforge.net  Thu Feb 26 13:00:50 2009
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 26 Feb 2009 12:00:50 +0000
Subject: [OpenSIPS-Devel] [ opensips-Bugs-2636710 ] rr (loose_route) should
	take aliases from domain module
Message-ID: <E1Lcev4-0002ef-Db@b55xhf1.ch3.sourceforge.com>

Bugs item #2636710, was opened at 2009-02-25 13:14
Message generated for change (Comment added) made by thomas_gelf
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=2636710&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: 6
Private: No
Submitted By: Thomas Gelf (thomas_gelf)
Assigned to: Bogdan-Andrei Iancu (bogdan_iancu)
Summary: rr (loose_route) should take aliases from domain module

Initial Comment:
OpenSIPS 1.5 (SVN, today) still needs aliases to be defined manually using alias=... - otherwise loose_route() doesn't detect them as "local", even if defined in the domain table.

Best regards,
Thomas Gelf


----------------------------------------------------------------------

>Comment By: Thomas Gelf (thomas_gelf)
Date: 2009-02-26 13:00

Message:
Compiled, installed, updated config (removed alias=), works fine! Also
tried adding / removing aliases with "opensipsctl domain ...", everything
seems to behave as expected.

Thanks a lot,
Thomas Gelf


----------------------------------------------------------------------

Comment By: Bogdan-Andrei Iancu (bogdan_iancu)
Date: 2009-02-26 11:00

Message:
Hi Thomas,

A fix in available on SVN - please update and give it one more try. As per
discussion on the IRC channel, for testing, remove the aliase="" from your
cfg file.

Regards,
Bogdan

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=2636710&group_id=232389


From noreply at sourceforge.net  Thu Feb 26 13:06:03 2009
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 26 Feb 2009 12:06:03 +0000
Subject: [OpenSIPS-Devel] [ opensips-Bugs-2636710 ] rr (loose_route) should
	take aliases from domain module
Message-ID: <E1Lcf07-0001qZ-Rf@1bkjzd1.ch3.sourceforge.com>

Bugs item #2636710, was opened at 2009-02-25 14:14
Message generated for change (Comment added) made by bogdan_iancu
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=2636710&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: 6
Private: No
Submitted By: Thomas Gelf (thomas_gelf)
Assigned to: Bogdan-Andrei Iancu (bogdan_iancu)
Summary: rr (loose_route) should take aliases from domain module

Initial Comment:
OpenSIPS 1.5 (SVN, today) still needs aliases to be defined manually using alias=... - otherwise loose_route() doesn't detect them as "local", even if defined in the domain table.

Best regards,
Thomas Gelf


----------------------------------------------------------------------

>Comment By: Bogdan-Andrei Iancu (bogdan_iancu)
Date: 2009-02-26 14:06

Message:
Cool :)

----------------------------------------------------------------------

Comment By: Thomas Gelf (thomas_gelf)
Date: 2009-02-26 14:00

Message:
Compiled, installed, updated config (removed alias=), works fine! Also
tried adding / removing aliases with "opensipsctl domain ...", everything
seems to behave as expected.

Thanks a lot,
Thomas Gelf


----------------------------------------------------------------------

Comment By: Bogdan-Andrei Iancu (bogdan_iancu)
Date: 2009-02-26 12:00

Message:
Hi Thomas,

A fix in available on SVN - please update and give it one more try. As per
discussion on the IRC channel, for testing, remove the aliase="" from your
cfg file.

Regards,
Bogdan

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=2636710&group_id=232389


From noreply at sourceforge.net  Thu Feb 26 13:10:07 2009
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 26 Feb 2009 12:10:07 +0000
Subject: [OpenSIPS-Devel] [ opensips-Bugs-2634285 ] Nat_traversal:
	opensipsctl ul rm doesn't clean up keepalives
Message-ID: <E1Lcf43-0002B8-K7@1bkjzd1.ch3.sourceforge.com>

Bugs item #2634285, was opened at 2009-02-24 18:11
Message generated for change (Comment added) made by thomas_gelf
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=2634285&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: Invalid
Priority: 5
Private: No
Submitted By: Thomas Gelf (thomas_gelf)
Assigned to: Dan (dan_pascu)
Summary: Nat_traversal: opensipsctl ul rm doesn't clean up keepalives

Initial Comment:
Running

> opensipsctl ul rm user at domain.tld

doesn't seem to affect nat_traversal's keep-alive state.

Steps I followed to reproduce this issue:
* removed all registrations
* stopped OpenSIPS
* removed keep-alive state file
* started OpenSIPS
* booted some test device
* let devices (all of them behind NAT) REGISTER themselves
* stopped OpenSIPS, manually compared usrloc entries and keep-alive state file
* everything seemed to be fine
* restarted OpenSIPS, "ul rm" for one user, stopped OpenSIPS
* old entry is still to be found in keep-alive state file

OpenSIPS version: SVN trunk, updated this morning. If you need more tests please let me know!

Best regards,
Thomas Gelf


----------------------------------------------------------------------

>Comment By: Thomas Gelf (thomas_gelf)
Date: 2009-02-26 13:10

Message:
Silly me, should have known that - sorry! Got confused as there have been
LOTS of keepalives because of a braindead ALG in my test environment ;-)

----------------------------------------------------------------------

Comment By: Dan (dan_pascu)
Date: 2009-02-25 12:20

Message:
The nat_traversal module doesn't use the ul module contacts, instead it
keeps track itself of the nat entry points (ip:port). These do not have a
1:1 relationship, as a nat entry point can be used by multiple contacts. So
when a contact is removed you can say nothing about the nat entry point not
being used anymore. The nat_traversal module will remove a nat entry point
from the keepalive list only when all the reasons to keep that address
alive expire. For a registration, that means when it expires. Read the
nat_traversal documentation for a detailed explanation of its operation.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=2634285&group_id=232389


From noreply at sourceforge.net  Thu Feb 26 13:13:48 2009
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 26 Feb 2009 12:13:48 +0000
Subject: [OpenSIPS-Devel] [ opensips-Bugs-2641453 ] Latest 1.5 trunk Debian
	packaging "make deb" fails
Message-ID: <E1Lcf7c-0002Qd-8S@1bkjzd1.ch3.sourceforge.com>

Bugs item #2641453, was opened at 2009-02-26 14:13
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=2641453&group_id=232389

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: packaging
Group: trunk
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Alex Massover (cupotka2008)
Assigned to: Nobody/Anonymous (nobody)
Summary: Latest 1.5 trunk Debian packaging "make deb" fails

Initial Comment:
Hi!

Debian packaging ("make deb") fails on latest trunk:

dpatch  apply-all  
applying patch 10_no_lib64_on_64_bits to ./ ... failed.
make[1]: *** [patch-stamp] Error 1
make[1]: Leaving directory `/tmp/opensips_head'
dpkg-buildpackage: failure: debian/rules build gave error exit status 2
make: *** [deb] Error 2

Best Regards,
Alex.




----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=2641453&group_id=232389


From noreply at sourceforge.net  Thu Feb 26 13:16:01 2009
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 26 Feb 2009 12:16:01 +0000
Subject: [OpenSIPS-Devel] [ opensips-Bugs-2641464 ] engage_media_proxy
	failes if called after create_dialog
Message-ID: <E1Lcf9l-0007Qa-0V@h45xhf1.ch3.sourceforge.com>

Bugs item #2641464, was opened at 2009-02-26 13:16
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=2641464&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: Thomas Gelf (thomas_gelf)
Assigned to: Nobody/Anonymous (nobody)
Summary: engage_media_proxy failes if called after create_dialog

Initial Comment:
If I correctly understood mediaproxy.c it installs a callback handler __dialog_created, responsible for setting up the other handlers for this dialog (using dlg_api.register_dlgcb).

However, if you called create_dialog() before, "dialog_created" will not be fired again if you are using engage_media_proxy().

Proposed solution: either add a note to current documentation ("...do NOT use create_dialog when using engage_media_proxy...") or find a way to catch this situation in EngageMediaProxy (maybe: if dlg started, immediately register dialog callbacks).

Best regards,
Thomas Gelf


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=2641464&group_id=232389


From noreply at sourceforge.net  Thu Feb 26 13:27:56 2009
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 26 Feb 2009 12:27:56 +0000
Subject: [OpenSIPS-Devel] [ opensips-Bugs-2641453 ] Latest 1.5 trunk Debian
	packaging "make deb" fails
Message-ID: <E1LcfLI-0001N2-Cx@d45xhf1.ch3.sourceforge.com>

Bugs item #2641453, was opened at 2009-02-26 13:13
Message generated for change (Comment added) made by thomas_gelf
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=2641453&group_id=232389

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: packaging
Group: trunk
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Alex Massover (cupotka2008)
Assigned to: Nobody/Anonymous (nobody)
Summary: Latest 1.5 trunk Debian packaging "make deb" fails

Initial Comment:
Hi!

Debian packaging ("make deb") fails on latest trunk:

dpatch  apply-all  
applying patch 10_no_lib64_on_64_bits to ./ ... failed.
make[1]: *** [patch-stamp] Error 1
make[1]: Leaving directory `/tmp/opensips_head'
dpkg-buildpackage: failure: debian/rules build gave error exit status 2
make: *** [deb] Error 2

Best Regards,
Alex.




----------------------------------------------------------------------

Comment By: Thomas Gelf (thomas_gelf)
Date: 2009-02-26 13:27

Message:
Hmmm... I've created packages from trunk 30 minutes ago, without any issue
(using dpkg-buildpackage, not make deb - but this shouldn't make any
difference).

Platform: Debian Lenny, 64bit.

Cheers,
Thomas Gelf


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=2641453&group_id=232389


From marc.leurent at vtx-telecom.ch  Thu Feb 26 13:48:31 2009
From: marc.leurent at vtx-telecom.ch (Marc Leurent)
Date: Thu, 26 Feb 2009 13:48:31 +0100
Subject: [OpenSIPS-Devel] Fwd: Re: [OpenSIPS-Users] OpenSIPs 1.4.4 rpm on
	CentOS - patch OK - should be uploaded in SVN repo!
Message-ID: <200902261348.31668.marc.leurent@vtx-telecom.ch>

Hello developpers,
Please read the messsage below!
Thanks,

Best Regards!


----------  Message transmis  ----------

Sujet?: Re: [OpenSIPS-Users] OpenSIPs 1.4.4 rpm on CentOS - patch OK - should  
be uploaded in SVN repo!
Date?: jeudi, 26 f?vrier 2009
De?: Julian Yap <julianokyap at gmail.com>
??: Marc Leurent <marc.leurent at vtx-telecom.ch>

Hi Marc,

That's great news.  Just wanted to give something back to the
community :P  I know a lot of people use CentOS such as myself.

Committers, please test and add with Changelog comment:
Thu Feb 26 2009 Julian Yap <julianokyap at gmail.com>
 * Update spec to OpenSIPS version 1.4.4. Rename database module
names. Rename PUA module. Fix dependencies. Minor build fixes.
Additional files and new modules.

Thanks,
Julian

On Thu, Feb 26, 2009 at 1:19 AM, Marc Leurent
<marc.leurent at vtx-telecom.ch> wrote:
> It's working! I have done exactly the same thing but without sorting 
sections
> in alphabetical order...
> For me this patch is great and should be added in svn repository!
> No error, no warning!!
>
> Julian, You should add a comment in the changelog!
>
>
> Checking for unpackaged
> file(s): /usr/lib/rpm/check-files /var/tmp/opensips-1.4.4-buildroot
> Wrote: /usr/src/redhat/RPMS/i386/opensips-1.4.4-0.i386.rpm
> Wrote: /usr/src/redhat/RPMS/i386/opensips-mysql-1.4.4-0.i386.rpm
> Wrote: /usr/src/redhat/RPMS/i386/opensips-postgres-1.4.4-0.i386.rpm
> Wrote: /usr/src/redhat/RPMS/i386/opensips-unixodbc-1.4.4-0.i386.rpm
> Wrote: /usr/src/redhat/RPMS/i386/opensips-jabber-1.4.4-0.i386.rpm
> Wrote: /usr/src/redhat/RPMS/i386/opensips-cpl-1.4.4-0.i386.rpm
> Wrote: /usr/src/redhat/RPMS/i386/opensips-pua-1.4.4-0.i386.rpm
> Wrote: /usr/src/redhat/RPMS/i386/opensips-radius-1.4.4-0.i386.rpm
> Executing(%clean): /bin/sh -e /var/tmp/rpm-tmp.33568
>
> Have a nice day
>
> Le Thursday 26 February 2009 11.47:07 Julian Yap, vous avez ?crit?:
>> Marc,
>>
>> Try this updated patch file.
>>
>> - Julian
>>
>> On Wed, Feb 25, 2009 at 11:41 PM, Marc Leurent
>>
>> <marc.leurent at vtx-telecom.ch> wrote:
>> > Hello,
>> > Thank you for the patch, I was closed to it :-)
>> > I have applied the patch and launched the following compilation command:
>> > rpmbuild -bb opensips.spec-4.4-julian
>> >
>> >> /root/opensips-compilation-spec-4.4-julian.log
>> >
>> > 2> /root/opensips-compilation-spec-4.4-julian-error.log
>> >
>> > and I have some strange error,
>> > I'm compiling it on
>> > CentOS 5.2
>> > Linux 2.6.18-92.1.22.el5PAE
>> > gcc version 4.1.2 20071124 (Red Hat 4.1.2-42)
>> >
>> > Please find enclosed the error log
>> > Any clue? I do not understand!
>> >
>> > Best Regards!
>> >
>> > Le Wednesday 25 February 2009 22.33:34 Julian Yap, vous avez ?crit?:
>> >> Hi Marc,
>> >>
>> >> I took a look at fixing the spec file.
>> >>
>> >> Try the attached patch file. ?Builds fine for me on CentOS 5.x 32-bit.
>> >>
>> >> Developers, please test and accept the patch!
>> >>
>> >> Thanks,
>> >> Julian
>> >>
>> >> On Wed, Feb 25, 2009 at 6:04 AM, Marc Leurent
>> >>
>> >> <marc.leurent at vtx-telecom.ch> wrote:
>> >> > Thank you for your answer,
>> >> > I have seen that you wrote this spec and I thank you for this, but,
>> >> > in the code retrieved from the opensips website:
>> >> > http://www.opensips.org/pub/opensips/1.4.4/src/opensips-1.4.4-tls_src.
>> >> >tar .gz the packaging/rpm/asterisk.spec-4.1 defines a 1.4.0 version
>> >> >
>> >> > here is the problem I had and how I solve them:
>> >> > 1) the version parameter was 1.4.0, I have replaced it with 1.4.4
>> >> > 2) the download URL has changed from
>> >> > http://opensips.org/pub/opensips/stable/%{name}-%{ver}_src.tar.gz
>> >> > to
>> >> > http://www.opensips.org/pub/opensips/%{ver}/src/%{name}-%{ver}-tls_src
>> >> >.ta r.gz 3) The name of the mysql module has change to db_mysql, so I
>> >> > had to change some lines into the spec file,...
>> >> > 4) the name of some build dependencies have changed on centOS, like
>> >> > unixODBC-devel, not unixodbc-dev,...
>> >> >
>> >> > Even without modifying the code to retrieve the 1.4.0 version, it
>> >> > wasn't working on centOS because of the download URL and the name of
>> >> > mysql module
>> >> >
>> >> > Unfortunatly, I cannot use Debian like I used to and its great
>> >> > packaging system, so I'm a little bit stuck...
>> >> >
>> >> > Thank you for your time.
>> >> > Have a nice afternoon!
>> >> >
>> >> > Le Wednesday 25 February 2009 15.05:22 Bogdan-Andrei Iancu, vous avez
>> >
>> > ?crit?:
>> >> >> Hi Marc,
>> >> >>
>> >> >> even if the name of the spec is misleading, it will build the 4.4
>> >> >> (the code you downloaded)....so, have you tried without changing the
>> >> >> script itself?
>> >> >>
>> >> >> Regards,
>> >> >> Bogdan
>> >> >>
>> >> >> Marc Leurent wrote:
>> >> >> > Hello everybody,
>> >> >> > I had to migrate from debian to centOS and I would like to build
>> >> >> > rpm packages of opensips on a CentOS dev server.
>> >> >> > I have retrieved the opensips.spec-4.1 file from the packaging
>> >> >> > folder in opensips source code and I'm trying to adapt it to
>> >> >> > opensips-4.4. I would be very grateful if someone that have already
>> >> >> > done that could help me...
>> >> >> >
>> >> >> > Best Regards,
>> >> >> >
>> >> >> > When compiling, I have some path error I'm trying to fix.
>> >> >> >
>> >> >> > rpmbuild -bb opensips.spec-4.4
>> >> >> > ....
>> >> >> > ....
>> >> >> > ....
>> >> >> > RPM build errors:
>> >> >> > ? ? File not found:
>> >> >> > /var/tmp/opensips-1.4.4-root/usr/sbin/opensips/opensipsctl File not
>> >> >> > found:
>> >> >> > /var/tmp/opensips-1.4.4-root/usr/share/doc/opensips/README.mysql
>> >> >> > File not
>> >> >> > found:
>> >> >> > /var/tmp/opensips-1.4.4-root/usr/lib/opensips/modules/mysql.so File
>> >> >> > not found:
>> >> >> > /var/tmp/opensips-1.4.4-root/usr/sbin/opensips_mysql.sh File not
>> >> >> > found:
>> >> >> > /var/tmp/opensips-1.4.4-root/usr/lib/opensipsctl/opensipsctl.mysql
>> >> >> > File not
>> >> >> > found:
>> >> >> > /var/tmp/opensips-1.4.4-root/usr/share/doc/opensips/README.postgres
>> >> >> > File not
>> >> >> > found:
>> >> >> > /var/tmp/opensips-1.4.4-root/usr/lib/opensips/modules/postgres.so
>> >> >> > File not found:
>> >> >> > /var/tmp/opensips-1.4.4-root/usr/sbin/opensips_postgres.sh File not
>> >> >> > found:
>> >> >> > /var/tmp/opensips-1.4.4-root/usr/lib/opensipsctl/opensipsctl.pgsql
>> >> >> > File not
>> >> >> > found:
>> >> >> > /var/tmp/opensips-1.4.4-root/usr/share/doc/opensips/README.unixodbc
>> >> >> > File not
>> >> >> > found:
>> >> >> > /var/tmp/opensips-1.4.4-root/usr/lib/opensips/modules/unixodbc.so
>> >> >> > File not
>> >> >> > found:
>> >> >> > /var/tmp/opensips-1.4.4-root/usr/share/doc/opensips/README.pa File
>> >> >> > not
>> >> >> > found: /var/tmp/opensips-1.4.4-root/usr/lib/opensips/modules/pa.so
>> >> >
>> >> > --
>> >> > -- --
>> >> > Marc LEURENT
>> >> > Ing?nieur VoIP
>> >> >
>> >> > DECKPOINT SA
>> >> > Une soci?t? du groupe VTX Telecom
>> >> > ================================================================
>> >> > Rue Eug?ne-Marziano 15 - 1227 Les Acacias
>> >> > http://www.vtx.ch - marc.leurent at vtx-telecom.ch
>> >> > ----------------------------------------------------------------
>> >> > VTX, votre partenaire telecom proche de vous !
>> >> > ================================================================
>> >> >
>> >> > _______________________________________________
>> >> > Users mailing list
>> >> > Users at lists.opensips.org
>> >> > http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>> >
>> > --
>> > -- --
>> > Marc LEURENT
>> > Ing?nieur VoIP
>> >
>> > DECKPOINT SA
>> > Une soci?t? du groupe VTX Telecom
>> > ================================================================
>> > Rue Eug?ne-Marziano 15 - 1227 Les Acacias
>> > http://www.vtx.ch - marc.leurent at vtx-telecom.ch
>> > ----------------------------------------------------------------
>> > VTX, votre partenaire telecom proche de vous !
>> > ================================================================
>
>
>
> --
> -- --
> Marc LEURENT
> Ing?nieur VoIP
>
> DECKPOINT SA
> Une soci?t? du groupe VTX Telecom
> ================================================================
> Rue Eug?ne-Marziano 15 - 1227 Les Acacias
> http://www.vtx.ch - marc.leurent at vtx-telecom.ch
> ----------------------------------------------------------------
> VTX, votre partenaire telecom proche de vous !
> ================================================================
>

-------------------------------------------------------

-- 
-- --
Marc LEURENT
Ing?nieur VoIP

DECKPOINT SA
Une soci?t? du groupe VTX Telecom
================================================================
Rue Eug?ne-Marziano 15 - 1227 Les Acacias
http://www.vtx.ch - marc.leurent at vtx-telecom.ch
----------------------------------------------------------------
VTX, votre partenaire telecom proche de vous !
================================================================


From noreply at sourceforge.net  Thu Feb 26 13:50:43 2009
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 26 Feb 2009 12:50:43 +0000
Subject: [OpenSIPS-Devel] [ opensips-Bugs-2641453 ] Latest 1.5 trunk Debian
	packaging "make deb" fails
Message-ID: <E1LcfhL-0007PT-Dg@cdv4jf1.ch3.sourceforge.com>

Bugs item #2641453, was opened at 2009-02-26 14:13
Message generated for change (Comment added) made by cupotka2008
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=2641453&group_id=232389

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: packaging
Group: trunk
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Alex Massover (cupotka2008)
Assigned to: Nobody/Anonymous (nobody)
Summary: Latest 1.5 trunk Debian packaging "make deb" fails

Initial Comment:
Hi!

Debian packaging ("make deb") fails on latest trunk:

dpatch  apply-all  
applying patch 10_no_lib64_on_64_bits to ./ ... failed.
make[1]: *** [patch-stamp] Error 1
make[1]: Leaving directory `/tmp/opensips_head'
dpkg-buildpackage: failure: debian/rules build gave error exit status 2
make: *** [deb] Error 2

Best Regards,
Alex.




----------------------------------------------------------------------

>Comment By: Alex Massover (cupotka2008)
Date: 2009-02-26 14:50

Message:
There's a difference. You can't run dpkg-buildpackage on new clean
downloaded trunk. /debian directory is created by "make deb".
I happens like following:

1. First "make deb" on clean svn gives:

dpatch  apply-all  
applying patch 10_no_lib64_on_64_bits to ./ ... failed.
make[1]: *** [patch-stamp] Error 1
make[1]: Leaving directory `/tmp/opensips_head'
dpkg-buildpackage: failure: debian/rules build gave error exit status 2
make: *** [deb] Error 2

2. After if I run dpkg-buildpackage it gives:

 debian/rules build
test -d debian/patched || install -d debian/patched
dpatch  apply-all  
applying patch 10_no_lib64_on_64_bits to ./ ... ok.
applying patch 11_always_smp to ./ ... failed.
make: *** [patch-stamp] Error 1

10_no_lib64_on_64_bits patch already ok, but still 11_always_smp fails.

3. One more time dpkg-buildpackage:

 debian/rules build
test -d debian/patched || install -d debian/patched
dpatch  apply-all  
applying patch 10_no_lib64_on_64_bits to ./ ... ok.
applying patch 11_always_smp to ./ ... ok.
dpatch  cat-all  >>patch-stampT

This run is already OK.

Looks like 3 tries of patching/depatching makes a trick.  

----------------------------------------------------------------------

Comment By: Thomas Gelf (thomas_gelf)
Date: 2009-02-26 14:27

Message:
Hmmm... I've created packages from trunk 30 minutes ago, without any issue
(using dpkg-buildpackage, not make deb - but this shouldn't make any
difference).

Platform: Debian Lenny, 64bit.

Cheers,
Thomas Gelf


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=2641453&group_id=232389


From bogdan at voice-system.ro  Thu Feb 26 14:06:40 2009
From: bogdan at voice-system.ro (Bogdan-Andrei Iancu)
Date: Thu, 26 Feb 2009 15:06:40 +0200
Subject: [OpenSIPS-Devel] Fwd: Re: [OpenSIPS-Users] OpenSIPs 1.4.4 rpm
 on	CentOS - patch OK - should be uploaded in SVN repo!
In-Reply-To: <200902261348.31668.marc.leurent@vtx-telecom.ch>
References: <200902261348.31668.marc.leurent@vtx-telecom.ch>
Message-ID: <49A693E0.6000009@voice-system.ro>

Hi Marc,

Please generate a patch including the changes and upload the patch on 
the tracker (see http://www.opensips.org/index.php?n=Development.Tracker)

Thanks and regards,
Bogdan

Marc Leurent wrote:
> Hello developpers,
> Please read the messsage below!
> Thanks,
>
> Best Regards!
>
>
> ----------  Message transmis  ----------
>
> Sujet : Re: [OpenSIPS-Users] OpenSIPs 1.4.4 rpm on CentOS - patch OK - should  
> be uploaded in SVN repo!
> Date : jeudi, 26 f?vrier 2009
> De : Julian Yap <julianokyap at gmail.com>
> ? : Marc Leurent <marc.leurent at vtx-telecom.ch>
>
> Hi Marc,
>
> That's great news.  Just wanted to give something back to the
> community :P  I know a lot of people use CentOS such as myself.
>
> Committers, please test and add with Changelog comment:
> Thu Feb 26 2009 Julian Yap <julianokyap at gmail.com>
>  * Update spec to OpenSIPS version 1.4.4. Rename database module
> names. Rename PUA module. Fix dependencies. Minor build fixes.
> Additional files and new modules.
>
> Thanks,
> Julian
>
> On Thu, Feb 26, 2009 at 1:19 AM, Marc Leurent
> <marc.leurent at vtx-telecom.ch> wrote:
>   
>> It's working! I have done exactly the same thing but without sorting 
>>     
> sections
>   
>> in alphabetical order...
>> For me this patch is great and should be added in svn repository!
>> No error, no warning!!
>>
>> Julian, You should add a comment in the changelog!
>>
>>
>> Checking for unpackaged
>> file(s): /usr/lib/rpm/check-files /var/tmp/opensips-1.4.4-buildroot
>> Wrote: /usr/src/redhat/RPMS/i386/opensips-1.4.4-0.i386.rpm
>> Wrote: /usr/src/redhat/RPMS/i386/opensips-mysql-1.4.4-0.i386.rpm
>> Wrote: /usr/src/redhat/RPMS/i386/opensips-postgres-1.4.4-0.i386.rpm
>> Wrote: /usr/src/redhat/RPMS/i386/opensips-unixodbc-1.4.4-0.i386.rpm
>> Wrote: /usr/src/redhat/RPMS/i386/opensips-jabber-1.4.4-0.i386.rpm
>> Wrote: /usr/src/redhat/RPMS/i386/opensips-cpl-1.4.4-0.i386.rpm
>> Wrote: /usr/src/redhat/RPMS/i386/opensips-pua-1.4.4-0.i386.rpm
>> Wrote: /usr/src/redhat/RPMS/i386/opensips-radius-1.4.4-0.i386.rpm
>> Executing(%clean): /bin/sh -e /var/tmp/rpm-tmp.33568
>>
>> Have a nice day
>>
>> Le Thursday 26 February 2009 11.47:07 Julian Yap, vous avez ?crit :
>>     
>>> Marc,
>>>
>>> Try this updated patch file.
>>>
>>> - Julian
>>>
>>> On Wed, Feb 25, 2009 at 11:41 PM, Marc Leurent
>>>
>>> <marc.leurent at vtx-telecom.ch> wrote:
>>>       
>>>> Hello,
>>>> Thank you for the patch, I was closed to it :-)
>>>> I have applied the patch and launched the following compilation command:
>>>> rpmbuild -bb opensips.spec-4.4-julian
>>>>
>>>>         
>>>>> /root/opensips-compilation-spec-4.4-julian.log
>>>>>           
>>>> 2> /root/opensips-compilation-spec-4.4-julian-error.log
>>>>
>>>> and I have some strange error,
>>>> I'm compiling it on
>>>> CentOS 5.2
>>>> Linux 2.6.18-92.1.22.el5PAE
>>>> gcc version 4.1.2 20071124 (Red Hat 4.1.2-42)
>>>>
>>>> Please find enclosed the error log
>>>> Any clue? I do not understand!
>>>>
>>>> Best Regards!
>>>>
>>>> Le Wednesday 25 February 2009 22.33:34 Julian Yap, vous avez ?crit :
>>>>         
>>>>> Hi Marc,
>>>>>
>>>>> I took a look at fixing the spec file.
>>>>>
>>>>> Try the attached patch file.  Builds fine for me on CentOS 5.x 32-bit.
>>>>>
>>>>> Developers, please test and accept the patch!
>>>>>
>>>>> Thanks,
>>>>> Julian
>>>>>
>>>>> On Wed, Feb 25, 2009 at 6:04 AM, Marc Leurent
>>>>>
>>>>> <marc.leurent at vtx-telecom.ch> wrote:
>>>>>           
>>>>>> Thank you for your answer,
>>>>>> I have seen that you wrote this spec and I thank you for this, but,
>>>>>> in the code retrieved from the opensips website:
>>>>>> http://www.opensips.org/pub/opensips/1.4.4/src/opensips-1.4.4-tls_src.
>>>>>> tar .gz the packaging/rpm/asterisk.spec-4.1 defines a 1.4.0 version
>>>>>>
>>>>>> here is the problem I had and how I solve them:
>>>>>> 1) the version parameter was 1.4.0, I have replaced it with 1.4.4
>>>>>> 2) the download URL has changed from
>>>>>> http://opensips.org/pub/opensips/stable/%{name}-%{ver}_src.tar.gz
>>>>>> to
>>>>>> http://www.opensips.org/pub/opensips/%{ver}/src/%{name}-%{ver}-tls_src
>>>>>> .ta r.gz 3) The name of the mysql module has change to db_mysql, so I
>>>>>> had to change some lines into the spec file,...
>>>>>> 4) the name of some build dependencies have changed on centOS, like
>>>>>> unixODBC-devel, not unixodbc-dev,...
>>>>>>
>>>>>> Even without modifying the code to retrieve the 1.4.0 version, it
>>>>>> wasn't working on centOS because of the download URL and the name of
>>>>>> mysql module
>>>>>>
>>>>>> Unfortunatly, I cannot use Debian like I used to and its great
>>>>>> packaging system, so I'm a little bit stuck...
>>>>>>
>>>>>> Thank you for your time.
>>>>>> Have a nice afternoon!
>>>>>>
>>>>>> Le Wednesday 25 February 2009 15.05:22 Bogdan-Andrei Iancu, vous avez
>>>>>>             
>>>> ?crit :
>>>>         
>>>>>>> Hi Marc,
>>>>>>>
>>>>>>> even if the name of the spec is misleading, it will build the 4.4
>>>>>>> (the code you downloaded)....so, have you tried without changing the
>>>>>>> script itself?
>>>>>>>
>>>>>>> Regards,
>>>>>>> Bogdan
>>>>>>>
>>>>>>> Marc Leurent wrote:
>>>>>>>               
>>>>>>>> Hello everybody,
>>>>>>>> I had to migrate from debian to centOS and I would like to build
>>>>>>>> rpm packages of opensips on a CentOS dev server.
>>>>>>>> I have retrieved the opensips.spec-4.1 file from the packaging
>>>>>>>> folder in opensips source code and I'm trying to adapt it to
>>>>>>>> opensips-4.4. I would be very grateful if someone that have already
>>>>>>>> done that could help me...
>>>>>>>>
>>>>>>>> Best Regards,
>>>>>>>>
>>>>>>>> When compiling, I have some path error I'm trying to fix.
>>>>>>>>
>>>>>>>> rpmbuild -bb opensips.spec-4.4
>>>>>>>> ....
>>>>>>>> ....
>>>>>>>> ....
>>>>>>>> RPM build errors:
>>>>>>>>     File not found:
>>>>>>>> /var/tmp/opensips-1.4.4-root/usr/sbin/opensips/opensipsctl File not
>>>>>>>> found:
>>>>>>>> /var/tmp/opensips-1.4.4-root/usr/share/doc/opensips/README.mysql
>>>>>>>> File not
>>>>>>>> found:
>>>>>>>> /var/tmp/opensips-1.4.4-root/usr/lib/opensips/modules/mysql.so File
>>>>>>>> not found:
>>>>>>>> /var/tmp/opensips-1.4.4-root/usr/sbin/opensips_mysql.sh File not
>>>>>>>> found:
>>>>>>>> /var/tmp/opensips-1.4.4-root/usr/lib/opensipsctl/opensipsctl.mysql
>>>>>>>> File not
>>>>>>>> found:
>>>>>>>> /var/tmp/opensips-1.4.4-root/usr/share/doc/opensips/README.postgres
>>>>>>>> File not
>>>>>>>> found:
>>>>>>>> /var/tmp/opensips-1.4.4-root/usr/lib/opensips/modules/postgres.so
>>>>>>>> File not found:
>>>>>>>> /var/tmp/opensips-1.4.4-root/usr/sbin/opensips_postgres.sh File not
>>>>>>>> found:
>>>>>>>> /var/tmp/opensips-1.4.4-root/usr/lib/opensipsctl/opensipsctl.pgsql
>>>>>>>> File not
>>>>>>>> found:
>>>>>>>> /var/tmp/opensips-1.4.4-root/usr/share/doc/opensips/README.unixodbc
>>>>>>>> File not
>>>>>>>> found:
>>>>>>>> /var/tmp/opensips-1.4.4-root/usr/lib/opensips/modules/unixodbc.so
>>>>>>>> File not
>>>>>>>> found:
>>>>>>>> /var/tmp/opensips-1.4.4-root/usr/share/doc/opensips/README.pa File
>>>>>>>> not
>>>>>>>> found: /var/tmp/opensips-1.4.4-root/usr/lib/opensips/modules/pa.so
>>>>>>>>                 
>>>>>> --
>>>>>> -- --
>>>>>> Marc LEURENT
>>>>>> Ing?nieur VoIP
>>>>>>
>>>>>> DECKPOINT SA
>>>>>> Une soci?t? du groupe VTX Telecom
>>>>>> ================================================================
>>>>>> Rue Eug?ne-Marziano 15 - 1227 Les Acacias
>>>>>> http://www.vtx.ch - marc.leurent at vtx-telecom.ch
>>>>>> ----------------------------------------------------------------
>>>>>> VTX, votre partenaire telecom proche de vous !
>>>>>> ================================================================
>>>>>>
>>>>>> _______________________________________________
>>>>>> Users mailing list
>>>>>> Users at lists.opensips.org
>>>>>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>>>>>             
>>>> --
>>>> -- --
>>>> Marc LEURENT
>>>> Ing?nieur VoIP
>>>>
>>>> DECKPOINT SA
>>>> Une soci?t? du groupe VTX Telecom
>>>> ================================================================
>>>> Rue Eug?ne-Marziano 15 - 1227 Les Acacias
>>>> http://www.vtx.ch - marc.leurent at vtx-telecom.ch
>>>> ----------------------------------------------------------------
>>>> VTX, votre partenaire telecom proche de vous !
>>>> ================================================================
>>>>         
>>
>> --
>> -- --
>> Marc LEURENT
>> Ing?nieur VoIP
>>
>> DECKPOINT SA
>> Une soci?t? du groupe VTX Telecom
>> ================================================================
>> Rue Eug?ne-Marziano 15 - 1227 Les Acacias
>> http://www.vtx.ch - marc.leurent at vtx-telecom.ch
>> ----------------------------------------------------------------
>> VTX, votre partenaire telecom proche de vous !
>> ================================================================
>>
>>     
>
> -------------------------------------------------------
>
>   



From noreply at sourceforge.net  Thu Feb 26 14:15:29 2009
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 26 Feb 2009 13:15:29 +0000
Subject: [OpenSIPS-Devel] [ opensips-Bugs-2641453 ] Latest 1.5 trunk Debian
	packaging "make deb" fails
Message-ID: <E1Lcg5J-00052w-KO@d45xhf1.ch3.sourceforge.com>

Bugs item #2641453, was opened at 2009-02-26 13:13
Message generated for change (Comment added) made by thomas_gelf
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=2641453&group_id=232389

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: packaging
Group: trunk
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Alex Massover (cupotka2008)
Assigned to: Nobody/Anonymous (nobody)
Summary: Latest 1.5 trunk Debian packaging "make deb" fails

Initial Comment:
Hi!

Debian packaging ("make deb") fails on latest trunk:

dpatch  apply-all  
applying patch 10_no_lib64_on_64_bits to ./ ... failed.
make[1]: *** [patch-stamp] Error 1
make[1]: Leaving directory `/tmp/opensips_head'
dpkg-buildpackage: failure: debian/rules build gave error exit status 2
make: *** [deb] Error 2

Best Regards,
Alex.




----------------------------------------------------------------------

Comment By: Thomas Gelf (thomas_gelf)
Date: 2009-02-26 14:15

Message:
To say it like Obama: YES I CAN ;-)
As long as I don't run "make deb" nobody removes my debian folder /
symlink (I'm keeping my personal one as I want each build to get it's own
version number) and svn update && dpkg-buildpackage succeeds.

I tried a fresh new checkout, make deb fails. And I can confirm your
failfailsucceed behaviour, same thing here.


----------------------------------------------------------------------

Comment By: Alex Massover (cupotka2008)
Date: 2009-02-26 13:50

Message:
There's a difference. You can't run dpkg-buildpackage on new clean
downloaded trunk. /debian directory is created by "make deb".
I happens like following:

1. First "make deb" on clean svn gives:

dpatch  apply-all  
applying patch 10_no_lib64_on_64_bits to ./ ... failed.
make[1]: *** [patch-stamp] Error 1
make[1]: Leaving directory `/tmp/opensips_head'
dpkg-buildpackage: failure: debian/rules build gave error exit status 2
make: *** [deb] Error 2

2. After if I run dpkg-buildpackage it gives:

 debian/rules build
test -d debian/patched || install -d debian/patched
dpatch  apply-all  
applying patch 10_no_lib64_on_64_bits to ./ ... ok.
applying patch 11_always_smp to ./ ... failed.
make: *** [patch-stamp] Error 1

10_no_lib64_on_64_bits patch already ok, but still 11_always_smp fails.

3. One more time dpkg-buildpackage:

 debian/rules build
test -d debian/patched || install -d debian/patched
dpatch  apply-all  
applying patch 10_no_lib64_on_64_bits to ./ ... ok.
applying patch 11_always_smp to ./ ... ok.
dpatch  cat-all  >>patch-stampT

This run is already OK.

Looks like 3 tries of patching/depatching makes a trick.  

----------------------------------------------------------------------

Comment By: Thomas Gelf (thomas_gelf)
Date: 2009-02-26 13:27

Message:
Hmmm... I've created packages from trunk 30 minutes ago, without any issue
(using dpkg-buildpackage, not make deb - but this shouldn't make any
difference).

Platform: Debian Lenny, 64bit.

Cheers,
Thomas Gelf


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=2641453&group_id=232389


From noreply at sourceforge.net  Thu Feb 26 14:32:59 2009
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 26 Feb 2009 13:32:59 +0000
Subject: [OpenSIPS-Devel] [ opensips-Patches-2641715 ] Working opensips.spec
	for CentOS RPM
Message-ID: <E1LcgMF-0002Eb-Sr@cdv4jf1.ch3.sourceforge.com>

Patches item #2641715, was opened at 2009-02-26 14:32
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086412&aid=2641715&group_id=232389

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: packaging
Group: 1.4.x
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Marc LEURENT (lftsy)
Assigned to: Nobody/Anonymous (nobody)
Summary: Working opensips.spec for CentOS RPM

Initial Comment:
You'll find attached a patch to replace broken opensips.spec-4.1 with working opensips.spec-4.4.
Here is the changelog:

Thu Feb 26 2009 Julian Yap <julianokyap at gmail.com>
 * Update spec to OpenSIPS version 1.4.4. Rename database module
names. Rename PUA module. Fix dependencies. Minor build fixes.
Additional files and new modules.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086412&aid=2641715&group_id=232389


From marc.leurent at vtx-telecom.ch  Thu Feb 26 14:59:43 2009
From: marc.leurent at vtx-telecom.ch (Marc Leurent)
Date: Thu, 26 Feb 2009 14:59:43 +0100
Subject: [OpenSIPS-Devel]
	=?iso-8859-1?q?Fwd=3A_Re=3A_=5BOpenSIPS-Users=5D?=
	=?iso-8859-1?q?_OpenSIPs_1=2E4=2E4_rpm_on=09CentOS_-_patch_OK_-_sh?=
	=?iso-8859-1?q?ould_be_uploaded_in_SVN_repo!?=
In-Reply-To: <49A693E0.6000009@voice-system.ro>
References: <200902261348.31668.marc.leurent@vtx-telecom.ch>
	<49A693E0.6000009@voice-system.ro>
Message-ID: <200902261459.43587.marc.leurent@vtx-telecom.ch>

Done!
Thank You

Le Thursday 26 February 2009 14.06:40 Bogdan-Andrei Iancu, vous avez ?crit?:
> Hi Marc,
>
> Please generate a patch including the changes and upload the patch on
> the tracker (see http://www.opensips.org/index.php?n=Development.Tracker)
>
> Thanks and regards,
> Bogdan
>
> Marc Leurent wrote:
> > Hello developpers,
> > Please read the messsage below!
> > Thanks,
> >
> > Best Regards!
> >
> >
> > ----------  Message transmis  ----------
> >
> > Sujet : Re: [OpenSIPS-Users] OpenSIPs 1.4.4 rpm on CentOS - patch OK -
> > should be uploaded in SVN repo!
> > Date : jeudi, 26 f?vrier 2009
> > De : Julian Yap <julianokyap at gmail.com>
> > ? : Marc Leurent <marc.leurent at vtx-telecom.ch>
> >
> > Hi Marc,
> >
> > That's great news.  Just wanted to give something back to the
> > community :P  I know a lot of people use CentOS such as myself.
> >
> > Committers, please test and add with Changelog comment:
> > Thu Feb 26 2009 Julian Yap <julianokyap at gmail.com>
> >  * Update spec to OpenSIPS version 1.4.4. Rename database module
> > names. Rename PUA module. Fix dependencies. Minor build fixes.
> > Additional files and new modules.
> >
> > Thanks,
> > Julian
> >
> > On Thu, Feb 26, 2009 at 1:19 AM, Marc Leurent
> >
> > <marc.leurent at vtx-telecom.ch> wrote:
> >> It's working! I have done exactly the same thing but without sorting
> >
> > sections
> >
> >> in alphabetical order...
> >> For me this patch is great and should be added in svn repository!
> >> No error, no warning!!
> >>
> >> Julian, You should add a comment in the changelog!
> >>
> >>
> >> Checking for unpackaged
> >> file(s): /usr/lib/rpm/check-files /var/tmp/opensips-1.4.4-buildroot
> >> Wrote: /usr/src/redhat/RPMS/i386/opensips-1.4.4-0.i386.rpm
> >> Wrote: /usr/src/redhat/RPMS/i386/opensips-mysql-1.4.4-0.i386.rpm
> >> Wrote: /usr/src/redhat/RPMS/i386/opensips-postgres-1.4.4-0.i386.rpm
> >> Wrote: /usr/src/redhat/RPMS/i386/opensips-unixodbc-1.4.4-0.i386.rpm
> >> Wrote: /usr/src/redhat/RPMS/i386/opensips-jabber-1.4.4-0.i386.rpm
> >> Wrote: /usr/src/redhat/RPMS/i386/opensips-cpl-1.4.4-0.i386.rpm
> >> Wrote: /usr/src/redhat/RPMS/i386/opensips-pua-1.4.4-0.i386.rpm
> >> Wrote: /usr/src/redhat/RPMS/i386/opensips-radius-1.4.4-0.i386.rpm
> >> Executing(%clean): /bin/sh -e /var/tmp/rpm-tmp.33568
> >>
> >> Have a nice day
> >>
> >> Le Thursday 26 February 2009 11.47:07 Julian Yap, vous avez ?crit :
> >>> Marc,
> >>>
> >>> Try this updated patch file.
> >>>
> >>> - Julian
> >>>
> >>> On Wed, Feb 25, 2009 at 11:41 PM, Marc Leurent
> >>>
> >>> <marc.leurent at vtx-telecom.ch> wrote:
> >>>> Hello,
> >>>> Thank you for the patch, I was closed to it :-)
> >>>> I have applied the patch and launched the following compilation
> >>>> command: rpmbuild -bb opensips.spec-4.4-julian
> >>>>
> >>>>> /root/opensips-compilation-spec-4.4-julian.log
> >>>>
> >>>> 2> /root/opensips-compilation-spec-4.4-julian-error.log
> >>>>
> >>>> and I have some strange error,
> >>>> I'm compiling it on
> >>>> CentOS 5.2
> >>>> Linux 2.6.18-92.1.22.el5PAE
> >>>> gcc version 4.1.2 20071124 (Red Hat 4.1.2-42)
> >>>>
> >>>> Please find enclosed the error log
> >>>> Any clue? I do not understand!
> >>>>
> >>>> Best Regards!
> >>>>
> >>>> Le Wednesday 25 February 2009 22.33:34 Julian Yap, vous avez ?crit :
> >>>>> Hi Marc,
> >>>>>
> >>>>> I took a look at fixing the spec file.
> >>>>>
> >>>>> Try the attached patch file.  Builds fine for me on CentOS 5.x
> >>>>> 32-bit.
> >>>>>
> >>>>> Developers, please test and accept the patch!
> >>>>>
> >>>>> Thanks,
> >>>>> Julian
> >>>>>
> >>>>> On Wed, Feb 25, 2009 at 6:04 AM, Marc Leurent
> >>>>>
> >>>>> <marc.leurent at vtx-telecom.ch> wrote:
> >>>>>> Thank you for your answer,
> >>>>>> I have seen that you wrote this spec and I thank you for this, but,
> >>>>>> in the code retrieved from the opensips website:
> >>>>>> http://www.opensips.org/pub/opensips/1.4.4/src/opensips-1.4.4-tls_sr
> >>>>>>c. tar .gz the packaging/rpm/asterisk.spec-4.1 defines a 1.4.0
> >>>>>> version
> >>>>>>
> >>>>>> here is the problem I had and how I solve them:
> >>>>>> 1) the version parameter was 1.4.0, I have replaced it with 1.4.4
> >>>>>> 2) the download URL has changed from
> >>>>>> http://opensips.org/pub/opensips/stable/%{name}-%{ver}_src.tar.gz
> >>>>>> to
> >>>>>> http://www.opensips.org/pub/opensips/%{ver}/src/%{name}-%{ver}-tls_s
> >>>>>>rc .ta r.gz 3) The name of the mysql module has change to db_mysql,
> >>>>>> so I had to change some lines into the spec file,...
> >>>>>> 4) the name of some build dependencies have changed on centOS, like
> >>>>>> unixODBC-devel, not unixodbc-dev,...
> >>>>>>
> >>>>>> Even without modifying the code to retrieve the 1.4.0 version, it
> >>>>>> wasn't working on centOS because of the download URL and the name of
> >>>>>> mysql module
> >>>>>>
> >>>>>> Unfortunatly, I cannot use Debian like I used to and its great
> >>>>>> packaging system, so I'm a little bit stuck...
> >>>>>>
> >>>>>> Thank you for your time.
> >>>>>> Have a nice afternoon!
> >>>>>>
> >>>>>> Le Wednesday 25 February 2009 15.05:22 Bogdan-Andrei Iancu, vous
> >>>>>> avez
> >>>>
> >>>> ?crit :
> >>>>>>> Hi Marc,
> >>>>>>>
> >>>>>>> even if the name of the spec is misleading, it will build the 4.4
> >>>>>>> (the code you downloaded)....so, have you tried without changing
> >>>>>>> the script itself?
> >>>>>>>
> >>>>>>> Regards,
> >>>>>>> Bogdan
> >>>>>>>
> >>>>>>> Marc Leurent wrote:
> >>>>>>>> Hello everybody,
> >>>>>>>> I had to migrate from debian to centOS and I would like to build
> >>>>>>>> rpm packages of opensips on a CentOS dev server.
> >>>>>>>> I have retrieved the opensips.spec-4.1 file from the packaging
> >>>>>>>> folder in opensips source code and I'm trying to adapt it to
> >>>>>>>> opensips-4.4. I would be very grateful if someone that have
> >>>>>>>> already done that could help me...
> >>>>>>>>
> >>>>>>>> Best Regards,
> >>>>>>>>
> >>>>>>>> When compiling, I have some path error I'm trying to fix.
> >>>>>>>>
> >>>>>>>> rpmbuild -bb opensips.spec-4.4
> >>>>>>>> ....
> >>>>>>>> ....
> >>>>>>>> ....
> >>>>>>>> RPM build errors:
> >>>>>>>>     File not found:
> >>>>>>>> /var/tmp/opensips-1.4.4-root/usr/sbin/opensips/opensipsctl File
> >>>>>>>> not found:
> >>>>>>>> /var/tmp/opensips-1.4.4-root/usr/share/doc/opensips/README.mysql
> >>>>>>>> File not
> >>>>>>>> found:
> >>>>>>>> /var/tmp/opensips-1.4.4-root/usr/lib/opensips/modules/mysql.so
> >>>>>>>> File not found:
> >>>>>>>> /var/tmp/opensips-1.4.4-root/usr/sbin/opensips_mysql.sh File not
> >>>>>>>> found:
> >>>>>>>> /var/tmp/opensips-1.4.4-root/usr/lib/opensipsctl/opensipsctl.mysql
> >>>>>>>> File not
> >>>>>>>> found:
> >>>>>>>> /var/tmp/opensips-1.4.4-root/usr/share/doc/opensips/README.postgre
> >>>>>>>>s File not
> >>>>>>>> found:
> >>>>>>>> /var/tmp/opensips-1.4.4-root/usr/lib/opensips/modules/postgres.so
> >>>>>>>> File not found:
> >>>>>>>> /var/tmp/opensips-1.4.4-root/usr/sbin/opensips_postgres.sh File
> >>>>>>>> not found:
> >>>>>>>> /var/tmp/opensips-1.4.4-root/usr/lib/opensipsctl/opensipsctl.pgsql
> >>>>>>>> File not
> >>>>>>>> found:
> >>>>>>>> /var/tmp/opensips-1.4.4-root/usr/share/doc/opensips/README.unixodb
> >>>>>>>>c File not
> >>>>>>>> found:
> >>>>>>>> /var/tmp/opensips-1.4.4-root/usr/lib/opensips/modules/unixodbc.so
> >>>>>>>> File not
> >>>>>>>> found:
> >>>>>>>> /var/tmp/opensips-1.4.4-root/usr/share/doc/opensips/README.pa File
> >>>>>>>> not
> >>>>>>>> found: /var/tmp/opensips-1.4.4-root/usr/lib/opensips/modules/pa.so
> >>>>>>
> >>>>>> --
> >>>>>> -- --
> >>>>>> Marc LEURENT
> >>>>>> Ing?nieur VoIP
> >>>>>>
> >>>>>> DECKPOINT SA
> >>>>>> Une soci?t? du groupe VTX Telecom
> >>>>>> ================================================================
> >>>>>> Rue Eug?ne-Marziano 15 - 1227 Les Acacias
> >>>>>> http://www.vtx.ch - marc.leurent at vtx-telecom.ch
> >>>>>> ----------------------------------------------------------------
> >>>>>> VTX, votre partenaire telecom proche de vous !
> >>>>>> ================================================================
> >>>>>>
> >>>>>> _______________________________________________
> >>>>>> Users mailing list
> >>>>>> Users at lists.opensips.org
> >>>>>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
> >>>>
> >>>> --
> >>>> -- --
> >>>> Marc LEURENT
> >>>> Ing?nieur VoIP
> >>>>
> >>>> DECKPOINT SA
> >>>> Une soci?t? du groupe VTX Telecom
> >>>> ================================================================
> >>>> Rue Eug?ne-Marziano 15 - 1227 Les Acacias
> >>>> http://www.vtx.ch - marc.leurent at vtx-telecom.ch
> >>>> ----------------------------------------------------------------
> >>>> VTX, votre partenaire telecom proche de vous !
> >>>> ================================================================
> >>
> >> --
> >> -- --
> >> Marc LEURENT
> >> Ing?nieur VoIP
> >>
> >> DECKPOINT SA
> >> Une soci?t? du groupe VTX Telecom
> >> ================================================================
> >> Rue Eug?ne-Marziano 15 - 1227 Les Acacias
> >> http://www.vtx.ch - marc.leurent at vtx-telecom.ch
> >> ----------------------------------------------------------------
> >> VTX, votre partenaire telecom proche de vous !
> >> ================================================================
> >
> > -------------------------------------------------------



-- 
-- --
Marc LEURENT
Ing?nieur VoIP

DECKPOINT SA
Une soci?t? du groupe VTX Telecom
================================================================
Rue Eug?ne-Marziano 15 - 1227 Les Acacias
http://www.vtx.ch - marc.leurent at vtx-telecom.ch
----------------------------------------------------------------
VTX, votre partenaire telecom proche de vous !
================================================================


From noreply at sourceforge.net  Thu Feb 26 15:39:57 2009
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 26 Feb 2009 14:39:57 +0000
Subject: [OpenSIPS-Devel] [ opensips-Bugs-2538399 ] Bug in presence when
	using fallback2db
Message-ID: <E1LchP3-0007j3-9G@155xhf1.ch3.sourceforge.com>

Bugs item #2538399, was opened at 2009-01-26 21:39
Message generated for change (Settings changed) made by anca_vamanu
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=2538399&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: Oren K (oren_k)
Assigned to: Anca Vamanu (anca_vamanu)
Summary: Bug in presence when using fallback2db

Initial Comment:
Hi,

While using the presence module, I run this scenario:

a. user1 SUBSCRIBE's to presence of user2
(subscription is now pending)

b. user2 allows user1 in pres-rules
(refreshWatchers is called, subscription is now active. user1 receives a NOTIFY from presence server with user2's current tuple and Subscription-State: active)

c. user2 PUBLISH'es a new presence tuple
-- at this point presence server should NOTIFY user1 of the new presence but it doesn't (that's the bug).


My modparams:

modparam("presence|presence_xml", "db_url", "mysql://root at localhost/opensips")

modparam("presence", "server_address", "sip:presence.example.com:10500")

modparam("presence", "fallback2db", 1)
modparam("presence", "clean_period", 30)


What I see in the debug trace is that get_subs_dialog (from notify.c) can't find any dialogs in the database, and all those in the subs hash are flagged NO_UPDATEDB_FLAG. This is probably what's causing the problem. 
Strangely, in the above scenario if user1 un-SUBSCRIBEs and re-SUBSCRIBEs to user2's presence - it does receive notifications.

Regards,
Oren K.

----------------------------------------------------------------------

>Comment By: Anca Vamanu (anca_vamanu)
Date: 2009-02-26 16:39

Message:
Great!

Anca

----------------------------------------------------------------------

Comment By: Oren K (oren_k)
Date: 2009-02-25 18:51

Message:
It's fixed!! awesome work, thanks!!

----------------------------------------------------------------------

Comment By: Anca Vamanu (anca_vamanu)
Date: 2009-02-25 18:44

Message:
Hi Oren,

I have tested myself and fixed it. I hope it also works for you. Please
update, test and reply.

regards,
Anca

----------------------------------------------------------------------

Comment By: Oren K (oren_k)
Date: 2009-02-24 16:44

Message:
It would appear that OpenSIPS does not reply in a timely manner:

Feb 23 12:34:58 openims /usr/local/sbin/opensips[3091]:
DBG:tm:utimer_routine: timer routine:4,tl=0xb6183d1c next=(nil),
timeout=974500000
Feb 23 12:35:01 openims opensips-mi-proxy[2368]: [-] error: Error while
processing command refreshWatchers (sip:user2 at openims.summit-tech.ca
presence 0): OpenSIP
S command did timeout

Strangely the first mi_refresh_watchers gets through, this exception only
happens in the second time its called. I'm attaching the logfile from this
run so you can have a look. OpenSIPS does not report any errors, but the
scenario still happens: No NOTIFY is received after user2 PUBLISHes.

----------------------------------------------------------------------

Comment By: Anca Vamanu (anca_vamanu)
Date: 2009-02-24 11:41

Message:
Hi, 

It does not help me if you say what error you get in opensips-mi-proxy. It
would have been better if you said what is the error in opensips :) .
Please look in the log, find the error and print it here.

regards, 
Anca

----------------------------------------------------------------------

Comment By: Oren K (oren_k)
Date: 2009-02-23 19:38

Message:
Thanks for your help Anca. I updated my sources from SVN and recompiled but
unfortunately the bug is still not resolved. I am still getting a crash
from opensips-mi-proxy, its the same one as on my previous comment from
Date: 2009-02-20 13:22

exceptions.ValueError: invalid literal for int() with base 10: 'OpenSIPS'

----------------------------------------------------------------------

Comment By: Anca Vamanu (anca_vamanu)
Date: 2009-02-23 15:57

Message:
Hi Oren,

I have fixed the problem with 'transformations' node. Please update and
test again.

Thanks,
Anca

----------------------------------------------------------------------

Comment By: Oren K (oren_k)
Date: 2009-02-20 20:53

Message:
also I was getting errors because I didn't have a transformations node. The
common-policy schema states that transformations isn't a must-have, and I
think opensips should treat no transformations node the same as if there
was an empty one.

<xs:element name="transformations" type="cp:extensibleType"
minOccurs="0"/>

However, adding a <transformations/> to my pres-rules had not effect on
this bug (still happens).

----------------------------------------------------------------------

Comment By: Oren K (oren_k)
Date: 2009-02-20 20:22

Message:
Something else is wrong now. mi_refresh_watchers is getting a timeout. This
didn't happen before. I'm using:
OpenXCAP 1.0.6
opensips-mi-proxy 1.0.2

Right now nothing works, not even normal scenarios.

Feb 20 13:16:22 openims opensips-mi-proxy[2368]: [-] error: Error while
processing command refreshWatchers (sip:user2 at openims.summit-tech.ca
presence 0): O
penSIPS command did timeout
Feb 20 13:16:22 openims opensips-mi-proxy[2368]: [-] Exception rendering:
Feb 20 13:16:22 openims opensips-mi-proxy[2368]: [-] Traceback (most
recent call last):
Feb 20 13:16:22 openims opensips-mi-proxy[2368]: [-]       File
"/usr/lib/python2.5/site-packages/Twisted-8.2.0_r25964-py2.5-linux-i686.egg/twisted/interne
t/defer.py", line 312, in _startRunCallbacks
Feb 20 13:16:22 openims opensips-mi-proxy[2368]: [-]        
self._runCallbacks()
Feb 20 13:16:22 openims opensips-mi-proxy[2368]: [-]       File
"/usr/lib/python2.5/site-packages/Twisted-8.2.0_r25964-py2.5-linux-i686.egg/twisted/interne
t/defer.py", line 328, in _runCallbacks
Feb 20 13:16:22 openims opensips-mi-proxy[2368]: [-]         self.result =
callback(self.result, *args, **kw)
Feb 20 13:16:22 openims opensips-mi-proxy[2368]: [-]       File
"/usr/lib/python2.5/site-packages/Twisted-8.2.0_r25964-py2.5-linux-i686.egg/twisted/interne
t/defer.py", line 289, in _continue
Feb 20 13:16:22 openims opensips-mi-proxy[2368]: [-]        
self.unpause()
Feb 20 13:16:22 openims opensips-mi-proxy[2368]: [-]       File
"/usr/lib/python2.5/site-packages/Twisted-8.2.0_r25964-py2.5-linux-i686.egg/twisted/interne
t/defer.py", line 285, in unpause
Feb 20 13:16:22 openims opensips-mi-proxy[2368]: [-]        
self._runCallbacks()
Feb 20 13:16:22 openims opensips-mi-proxy[2368]: [-]     --- <exception
caught here> ---
Feb 20 13:16:22 openims opensips-mi-proxy[2368]: [-]       File
"/usr/lib/python2.5/site-packages/Twisted-8.2.0_r25964-py2.5-linux-i686.egg/twisted/interne
t/defer.py", line 328, in _runCallbacks
Feb 20 13:16:22 openims opensips-mi-proxy[2368]: [-]         self.result =
callback(self.result, *args, **kw)
Feb 20 13:16:22 openims opensips-mi-proxy[2368]: [-]       File
"/usr/lib/python2.5/site-packages/miproxy/proxy.py", line 89, in _cbRender
Feb 20 13:16:22 openims opensips-mi-proxy[2368]: [-]         code =
int(code)
Feb 20 13:16:22 openims opensips-mi-proxy[2368]: [-]    
exceptions.ValueError: invalid literal for int() with base 10: 'OpenSIPS'


----------------------------------------------------------------------

Comment By: Anca Vamanu (anca_vamanu)
Date: 2009-02-20 14:59

Message:
Hi,

I have just made a fix. Please update, test again and reply.

Thanks,
Anca

----------------------------------------------------------------------

Comment By: Anca Vamanu (anca_vamanu)
Date: 2009-02-20 14:25

Message:
Hi Oren,

I have looked into the log file that you posted and saw that there was and
error there. There is a problem with the body of the Publish message -
which causes stopping the processing. The problem is that the code in the
presence server expects a tuple element in the body - and the body of the
last Publish message does not contain one.
I have looked up in the RFC and saw that the tuple element is in fact not
compulsory - so there is a bug in the presence code - but not the one you
reported :). 
I will fix this soon.

Thanks and regards,
Anca

----------------------------------------------------------------------

Comment By: Oren K (oren_k)
Date: 2009-02-20 01:42

Message:
Still no joy.. adding updated log and pcap for the version i compiled from
svn 1.5.0dev5-tls.

----------------------------------------------------------------------

Comment By: Anca Vamanu (anca_vamanu)
Date: 2009-02-18 18:11

Message:
Hi, 

I have just now made some changes in presence module for fallback2db case.
Can you please update to the newest svn version for 1.5 and test again?

regards,
Anca

----------------------------------------------------------------------

Comment By: Anca Vamanu (anca_vamanu)
Date: 2009-02-18 18:10

Message:
Hi, 

I have just now made some changes in presence module for fallback2db case.
Can you please update to the newest svn version for 1.5 and test again?

regards,
Anca

----------------------------------------------------------------------

Comment By: Oren K (oren_k)
Date: 2009-02-07 02:23

Message:
Hi Anca,

I've attached a debug-log and wireshark pcap file to the post. The pcap
file also contains the XCAP PUTs to change the presence rules. The only
error in the log comes from presence_xml not being able to extract a tuple
node because our client uses <pdm:person> for the presence (Same bug
happened to us when we tried with <tuple> so that's not the issue). The
things that strike me odd in presence_bug.log are:

(after step b. user2 allows user1 in pres-rules)
line 634: DBG:presence:update_pw_dialogs: found 1 matching dialogs

the module finds the watcher dialog and updates it due to refreshWatchers.
user1 receives a NOTIFY with Subscription-State:active. Now step c. user2
PUBLISH'es a new presence tuple:

line 919: DBG:core:parse_msg:  method:  <PUBLISH>

everything looks okay BUT:

line 1087: DBG:presence:get_subs_db: The query for subscribtion for [uri]=
sip:user2 at openims.summit-tech.ca for [event]= presence returned no result
line 1110: DBG:presence:get_subs_dialog: s->db_flag== UPDATEDB_FLAG
line 1111: DBG:presence:get_subs_dialog: found 0 dialogs( 0 in database
and 0 in hash_table)
line 1112: DBG:presence:publ_notify: Could not find subs_dialog

..suddenly there are no subscribers?

Thanks.


----------------------------------------------------------------------

Comment By: Anca Vamanu (anca_vamanu)
Date: 2009-02-06 20:14

Message:
Hi Oren,

I have just downloaded myself the release and tested and the scenario that
you described works. 
Do you notice any error in your log file?

regards,
Anca

----------------------------------------------------------------------

Comment By: Oren K (oren_k)
Date: 2009-02-01 18:41

Message:
Sorry I forgot to login, that comment is from me :)

----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2009-01-28 17:12

Message:
Thanks for the reply anca. Version is opensips-1.4.4-tls, compiled from the
sources with TLS="1". 

----------------------------------------------------------------------

Comment By: Anca Vamanu (anca_vamanu)
Date: 2009-01-28 13:48

Message:
Hi Oren,

What OpenSIPS version are you using? Trunk or stable release?

regards,
Anca

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=2538399&group_id=232389


From noreply at sourceforge.net  Thu Feb 26 19:30:12 2009
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 26 Feb 2009 18:30:12 +0000
Subject: [OpenSIPS-Devel] [ opensips-Bugs-2642701 ] Bug in db_postgres and
	BLOB handling+patch
Message-ID: <E1Lckzs-0001bG-3l@h45xhf1.ch3.sourceforge.com>

Bugs item #2642701, was opened at 2009-02-26 20:30
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=2642701&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: Vasil Kolev (krokodilerian)
Assigned to: Nobody/Anonymous (nobody)
Summary: Bug in db_postgres and BLOB handling+patch

Initial Comment:
After digging more in the db_postgres driver and problems with XML with appended characters, I looked into PGunescape (which is used on BLOB fields) and turns out it doesn't add NULL termination on the strings. It wouldn't be a problem if some other code didnt't rely on strlen() of such fields...

The NULL termination will always work, as PGunescape allocates one more byte for the field (to work around malloc(0)/realloc(0)).

Patch attached.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=2642701&group_id=232389


From bogdan at voice-system.ro  Thu Feb 26 19:31:06 2009
From: bogdan at voice-system.ro (Bogdan-Andrei Iancu)
Date: Thu, 26 Feb 2009 18:31:06 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[5371] trunk/Makefile.defs
Message-ID: <E1Lcl0k-0005up-Uv@3kljzd1.ch3.sourceforge.com>

Revision: 5371
          http://opensips.svn.sourceforge.net/opensips/?rev=5371&view=rev
Author:   bogdan_iancu
Date:     2009-02-26 18:31:06 +0000 (Thu, 26 Feb 2009)

Log Message:
-----------
- reverted some changes automatically done by "make deb" and uploaded by mistake on SVN.

  Thanks to Norman Brandinger to spot this.

Modified Paths:
--------------
    trunk/Makefile.defs


This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site.


From noreply at sourceforge.net  Thu Feb 26 19:38:54 2009
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu, 26 Feb 2009 18:38:54 +0000
Subject: [OpenSIPS-Devel] [ opensips-Bugs-2642701 ] Bug in db_postgres and
	BLOB handling+patch
Message-ID: <E1Lcl8I-0006Vp-HQ@g45xhf1.ch3.sourceforge.com>

Bugs item #2642701, was opened at 2009-02-26 20:30
Message generated for change (Comment added) made by bogdan_iancu
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=2642701&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: Vasil Kolev (krokodilerian)
Assigned to: Nobody/Anonymous (nobody)
Summary: Bug in db_postgres and BLOB handling+patch

Initial Comment:
After digging more in the db_postgres driver and problems with XML with appended characters, I looked into PGunescape (which is used on BLOB fields) and turns out it doesn't add NULL termination on the strings. It wouldn't be a problem if some other code didnt't rely on strlen() of such fields...

The NULL termination will always work, as PGunescape allocates one more byte for the field (to work around malloc(0)/realloc(0)).

Patch attached.

----------------------------------------------------------------------

>Comment By: Bogdan-Andrei Iancu (bogdan_iancu)
Date: 2009-02-26 20:38

Message:
Vasil, is this related to 2636665 ?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=2642701&group_id=232389


From noreply at sourceforge.net  Fri Feb 27 10:37:17 2009
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 27 Feb 2009 09:37:17 +0000
Subject: [OpenSIPS-Devel] [ opensips-Bugs-2642701 ] Bug in db_postgres and
	BLOB handling+patch
Message-ID: <E1Lcz9h-0007Zl-A6@155xhf1.ch3.sourceforge.com>

Bugs item #2642701, was opened at 2009-02-26 20:30
Message generated for change (Comment added) made by krokodilerian
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=2642701&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: Vasil Kolev (krokodilerian)
Assigned to: Nobody/Anonymous (nobody)
Summary: Bug in db_postgres and BLOB handling+patch

Initial Comment:
After digging more in the db_postgres driver and problems with XML with appended characters, I looked into PGunescape (which is used on BLOB fields) and turns out it doesn't add NULL termination on the strings. It wouldn't be a problem if some other code didnt't rely on strlen() of such fields...

The NULL termination will always work, as PGunescape allocates one more byte for the field (to work around malloc(0)/realloc(0)).

Patch attached.

----------------------------------------------------------------------

>Comment By: Vasil Kolev (krokodilerian)
Date: 2009-02-27 11:37

Message:
Bogdan, yes, it's the second part of the problem. With both patches the
issues with db_postgres should go away.

----------------------------------------------------------------------

Comment By: Bogdan-Andrei Iancu (bogdan_iancu)
Date: 2009-02-26 20:38

Message:
Vasil, is this related to 2636665 ?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=2642701&group_id=232389


From rod at racequeen.ph  Thu Feb 26 01:57:19 2009
From: rod at racequeen.ph (bay2x1)
Date: Wed, 25 Feb 2009 16:57:19 -0800 (PST)
Subject: [OpenSIPS-Devel]  Help on understanding the rating engine!
Message-ID: <1235609839982-2387145.post@n2.nabble.com>


I have manage to install cdrtool and its working. The accounting part is okay
but the rating engine is not generating price per call. Looking at the
details of the call I see free call from the rating information.  I
understand that the rating engine determines the 1. billing part 2.
destination of the call 3. cost computation.  I don't I understand why the
rating engine treats each call as a free call? Any idea please? What do I
have to set to make the rating engine works properly?

-- 
View this message in context: http://n2.nabble.com/Help-on-understanding-the-rating-engine%21-tp2387145p2387145.html
Sent from the OpenSIPS - Devel mailing list archive at Nabble.com.



From noreply at sourceforge.net  Fri Feb 27 11:48:24 2009
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 27 Feb 2009 10:48:24 +0000
Subject: [OpenSIPS-Devel] [ opensips-Bugs-2641464 ] engage_media_proxy
	failes if called after create_dialog
Message-ID: <E1Ld0GW-0000C3-4R@1bkjzd1.ch3.sourceforge.com>

Bugs item #2641464, was opened at 2009-02-26 14:16
Message generated for change (Comment added) made by dan_pascu
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=2641464&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: Thomas Gelf (thomas_gelf)
Assigned to: Nobody/Anonymous (nobody)
Summary: engage_media_proxy failes if called after create_dialog

Initial Comment:
If I correctly understood mediaproxy.c it installs a callback handler __dialog_created, responsible for setting up the other handlers for this dialog (using dlg_api.register_dlgcb).

However, if you called create_dialog() before, "dialog_created" will not be fired again if you are using engage_media_proxy().

Proposed solution: either add a note to current documentation ("...do NOT use create_dialog when using engage_media_proxy...") or find a way to catch this situation in EngageMediaProxy (maybe: if dlg started, immediately register dialog callbacks).

Best regards,
Thomas Gelf


----------------------------------------------------------------------

>Comment By: Dan (dan_pascu)
Date: 2009-02-27 12:48

Message:
I think that the dialog module should immediately trigger the registered
callback for create dialog, if the dialog was created before that point.
This is the most obvious thing to do, as the code using the dialog module
will not have to be aware of the internal details of the dialog module and
its state, nor will it need to inspect the dialog module to figure out what
to do next.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=2641464&group_id=232389


From noreply at sourceforge.net  Fri Feb 27 12:24:58 2009
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 27 Feb 2009 11:24:58 +0000
Subject: [OpenSIPS-Devel] [ opensips-Bugs-2591935 ] Error in sending NOTIFY
	for PUBLISH in RLS mode
Message-ID: <E1Ld0pu-00085E-To@h45xhf1.ch3.sourceforge.com>

Bugs item #2591935, was opened at 2009-02-12 12:01
Message generated for change (Comment added) made by rmnathan
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=2591935&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: Nathan (rmnathan)
Assigned to: Anca Vamanu (anca_vamanu)
Summary: Error in sending NOTIFY for PUBLISH in RLS mode

Initial Comment:
Hi
When opensips got publish for the user(say E1_1) which has in two list subscriptions, it is sending notify to one user only.
For example:
UE2_1 list will have 2 entry uri like E1_1,E1_2
UE2_2 list will have 2 entry uri like E1_2,E1_1

S2_1 subscribe to UE2_1
S2_2 subscribe to UE2_2
If E1_1 send publish, opensips sends notify to S2_1 only. But it should send notify to S2_2 too.

Please find the attached pcap file for detailed call flow.

Regards,
rmnathan


----------------------------------------------------------------------

Comment By: Nathan (rmnathan)
Date: 2009-02-27 16:54

Message:
Hi Anca,
This issue is fixed. 
Thanks a lot.

Regards,
rmnathan

----------------------------------------------------------------------

Comment By: Nathan (rmnathan)
Date: 2009-02-25 18:32

Message:
Hi Anca,
Thanks for your reply.
I can't understand one thing.

Step 1:
c3-1_list has two users as s3-1 and s3-2
c3-2_list has two users as s3-1 and s3-2

Step 2:
c3-1 subscribe to c3-1_list
c3-2 subscribe to c3-2_list

Step 3:
If RLS gets publish from s3-1
it is sending NOTIFY to c3-1 one only. It is not sending  NOTIFY to c3-2.
can u explain why it is not sending NOTIFY to c3-2.

My doubt is s3-1 is in both the lists (ie c3-1 and c3-2). But RLS sending
notify to c3-1 one only. It is not sending to c3-2.

Regards
rmnathan


 

----------------------------------------------------------------------

Comment By: Anca Vamanu (anca_vamanu)
Date: 2009-02-25 16:14

Message:
Hi Nathan,

I have looked in the trace and for me it looks perfectly ok.

I don't understand what you say is wrong.8.

 
   ' iii) from s3-1 to c3-1 this is not correct. it should send from s3-1
to c3-2 '

    You are referring to message number 65 ( or 71 which is a
retransmission of 65), right? And you what to say that the To header is
wrong? 
If this is true, then you are wrong. The To header is exactly the same as
in the initial Subscribe received from the proxy. Please do filter on
Call-ID and check this yourself.     
   
    'iV) from s3-2 to c3-2 this is not correct. it should send from s3-2
to c3-1'
The same here.

regards,
Anca



----------------------------------------------------------------------

Comment By: Nathan (rmnathan)
Date: 2009-02-24 20:49

Message:
Hi Anca,

For the same setup
Test setup details
IMS UE1 192.168.165.151:5070
IMS UE2 192.168.165.152:5075
Proxy - SCSCF (192.168.166.150:50602)
Opensips(presence server) (10.6.2.246:5060)
RLS (10.6.2.246:5060)

The difference is two users in the IMS UE1 users list

IMS UE1 has two users
1.c3-1 which has s3-1 in list

<?xml version="1.0" encoding="UTF-8"?>
 <rls-services>
 <service uri="sip:c3-1_list at 10.6.2.246">
   <list name="c3-1">
    <entry uri="sip:s3-1 at 10.6.2.246"/>
    <entry uri="sip:s3-2 at 10.6.2.246"/>
   </list>
   <packages>
    <package>presence</package>
   </packages>
  </service>


2.c3-2 which has also s3-1 in list

<?xml version="1.0" encoding="UTF-8"?>
 <rls-services>
 <service uri="sip:c3-2_list at 10.6.2.246">
   <list name="c3-2">
    <entry uri="sip:s3-1 at 10.6.2.246"/>
    <entry uri="sip:s3-2 at 10.6.2.246"/>
   </list>
   <packages>
    <package>presence</package>
   </packages>
  </service>
 </rls-services>


IMS UE2 has one user
1.s3-1 ( this is only to send publish)
2.s3-2 (this is only to send publish)

call flow description
=====================
1.IMS UE1 ie(c3-1 and c3-2) will send subcribe to their list
2. Presence server that receives the Subscribe messages sent by the rls
server for the list subscription because the users
  in the list are same domain of presence server. So RLS server sends
subscribe, 200 ok for subscribe , Notify and 200 ok
  for notify to presence server(ie to itself because opensips and RLS
server running on same IP: 10.6.2.246)
3. After got 200 ok for subscribe and notify  for IMS UE1 users
4. Send subscribe from IMS UE2 (ie s3-1 to c3-1 & s3-2 to c3-2) . This is
just to send publish.
5. Then send publish from s3-1 and s3-2  ie from IMS UE2.
6. After got publish RLS server should generate notify to c3-1 and c3-2
because c3-1 & c3-2 have subscribed to s3-1 and s3-2
7. From captured trace RLS server sends notify and 200 ok for notify to
presence server 
Analysis
=========
8. Then after that RLS sends notify to IMS UE1
    i) from s3-1 to c3-1
    ii) from s3-2 to c3-2
    iii) from s3-1 to c3-1 this is not correct. it should send from s3-1
to c3-2
    iV) from s3-2 to c3-2 this is not correct. it should send from s3-2 to
c3-1

Please find captured trace also.

Regards
rmnathan

----------------------------------------------------------------------

Comment By: Nathan (rmnathan)
Date: 2009-02-24 19:14

Message:
Hi,
Test setup details
IMS UE1 192.168.165.151:5070
IMS UE2  192.168.165.152:5075
Proxy - SCSCF (192.168.166.150:50602)
Opensips(presence server) (10.6.2.246:5060) 
RLS (10.6.2.246:5060)



----------------------------------------------------------------------

Comment By: Nathan (rmnathan)
Date: 2009-02-24 19:07

Message:
Hi Anca

Test setup description:
======================

IMS UE1
192.168.165.151:5070
				Proxy - SCSCF            ----  Opensips(presence server)   ---- RLS
server
			  (192.168.166.150:50602)	       (10.6.2.246:5060)               
(10.6.2.246:5060)
IMS UE2
192.168.165.152:5075


IMS UE1 has two users 
1.c3-1 which has s3-1 in list

<?xml version="1.0" encoding="UTF-8"?>
 <rls-services>
 <service uri="sip:c3-1_list at 10.6.2.246">
   <list name="c3-1">
    <entry uri="sip:s3-1 at 10.6.2.246"/>

   </list>
   <packages>
    <package>presence</package>
   </packages>
  </service>
 </rls-services>

2.c3-2 which has also s3-1 in list

<?xml version="1.0" encoding="UTF-8"?>
 <rls-services>
 <service uri="sip:c3-2_list at 10.6.2.246">
   <list name="c3-2">
    <entry uri="sip:s3-1 at 10.6.2.246"/>

   </list>
   <packages>
    <package>presence</package>
   </packages>
  </service>
 </rls-services>

IMS UE2 has one user
1.s3-1 ( this is only to send publish)


call flow description
=====================
1.IMS UE1 ie(c3-1 and c3-2) will send subcribe to their list
2. Presence server that receives the Subscribe messages sent by the rls
server for the list subscription because the users
  in the list are same domain of presence server. So RLS server sends
subscribe, 200 ok for subscribe , Notify and 200 ok
  for notify to presence server(ie to itself because opensips and RLS
server running on same IP: 10.6.2.246)
3. After got 200 ok for subscribe and notify  for IMS UE1 users
4. Send subscribe from IMS UE2 (ie s3-1 to c3-1) . This is just to send
publish.
5. Then send publish from s3-1 ie from IMS UE2. 
6. After got publish RLS server should generate notify to c3-1 and c3-2
because c3-1 & c3-2 have subscribed to s3-1 
7. From captured trace RLS server sends notify and 200 ok for notify to
presence server (please explain why this is sending notify to opensips)
8. Then after that RLS sends notify to IMS UE1

9. refreshed Publish from IMS UE2
10 Removed Publish  from IMS UE2


For your queries
================
do you use a presence server that receives the
Subscribe messages sent by the rls server and also Publish messages from
the clients?

yes presence server receives the subscribe messages sent by the rls
server. The publish from clients (in this case from s3-1 (IMS UE2)

2.you send the Subscribes directly to the clients and they
reply with Notifies?
No. the subscribes sends to presence server by the rls server.

Please let me know if you want more information.
Please find captured trace also.

Regards
rmnathan


----------------------------------------------------------------------

Comment By: Anca Vamanu (anca_vamanu)
Date: 2009-02-24 18:22

Message:
Hi Rmnathan,

If you really want to help me figure out what your problem is you have to
send simpler traces. Your trace is impossible to analize - you have 8 lists
with different names, but there are 4 pairs having the same content - so
there are actually only 4 unique lists. Then you use in 'From' header of
the SUBSCRIBE not the name of the list but anther uri - this is not
important in the SIP logic - but it makes impossible for me to follow the
messages since the Notifies that the RLS sends and receives will have the
same To and From headers.
Please if you want to help run a simpler case - only two Subscriptions to
lists that can have different names but the same content. 
One more question - do you use a presence server that receives the
Subscribe messages sent by the rls server and also Publish messages from
the clients? Or you send the Subscribes directly to the clients and they
reply with Notifies?
Please also include a description with the entities in the scenario and
the IP address and port they run at.

Thanks,
Anca


----------------------------------------------------------------------

Comment By: Anca Vamanu (anca_vamanu)
Date: 2009-02-24 16:59

Message:
Hi Rmnathan,

If you really want to help me figure out what your problem is you have to
send simpler traces. Your trace is impossible to analize - you have 8 lists
with different names, but there are 4 pairs having the same content - so
there are actually only 4 unique lists. Then you use in 'From' header of
the SUBSCRIBE not the name of the list but anther uri - this is not
important in the SIP logic - but it makes impossible for me to follow the
messages since the Notifies that the RLS sends and receives will have the
same To and From headers.
Please if you want to help run a simpler case - only two Subscriptions to
lists that can have different names but the same content. 
One more question - do you use a presence server that receives the
Subscribe messages sent by the rls server and also Publish messages from
the clients? Or you send the Subscribes directly to the clients and they
reply with Notifies?
Please also include a description with the entities in the scenario and
the IP address and port they run at.

Thanks,
Anca


----------------------------------------------------------------------

Comment By: Nathan (rmnathan)
Date: 2009-02-24 16:13

Message:
Hi Anca,
After that i have tested. still the issue is not fixed. Now opensips is
generating notify for all the users(for first user) in the list but it
always sending to first user in the list only not for other users. 

Please see the attached pcap file.

Regards
rmnathan



----------------------------------------------------------------------

Comment By: Anca Vamanu (anca_vamanu)
Date: 2009-02-24 15:19

Message:
Hi Rmnathan,

A change was made for many tables - changing varchar type to char and
since the structure was changed, the version of the tables was increased.
You need to get the new mysql script and recreate the table and also
update the version for rls_presentity table in 'version' table. However
since there are many tables for which the version was increased I would
recommend recreating the whole database.

regards,
Anca

----------------------------------------------------------------------

Comment By: Nathan (rmnathan)
Date: 2009-02-24 11:53

Message:
Hi Anca,
I tried with latest trunk 5354 build. while starting opensips i got
following error message
stinbng46:/usr/local/trunk# /usr/local/sbin/opensips
Listening on
             udp: 10.6.2.246 [10.6.2.246]:5060
Aliases:
             udp: stinbng46:5060

stinbng46:/usr/local/trunk# Feb 24 11:46:35 [2520]
ERROR:core:db_check_table_version: invalid version 0 for table
rls_presentity found, expected 1
Feb 24 11:46:35 [2520] ERROR:rls:mod_init: error during table version
check.
Feb 24 11:46:35 [2520] ERROR:core:init_mod: failed to initialize module
rls
Feb 24 11:46:35 [2520] ERROR:core:main: error while initializing modules
i have   rls_presentity table also in opensips database.
mysql> desc rls_presentity
    -> ;
+----------------+------------------+------+-----+---------+----------------+
| Field          | Type             | Null | Key | Default | Extra        
 |
+----------------+------------------+------+-----+---------+----------------+
| id             | int(10) unsigned | NO   | PRI | NULL    |
auto_increment |
| rlsubs_did     | char(255)        | NO   | MUL |         |              
 |
| resource_uri   | char(128)        | NO   |     |         |              
 |
| content_type   | char(64)         | NO   |     |         |              
 |
| presence_state | blob             | NO   |     |         |              
 |
| expires        | int(11)          | NO   |     |         |              
 |
| updated        | int(11)          | NO   | MUL |         |              
 |
| auth_state     | int(11)          | NO   |     |         |              
 |
| reason         | char(64)         | NO   |     |         |              
 |
+----------------+------------------+------+-----+---------+----------------+
9 rows in set (0.00 sec)

I have changed and tried table version in script also 
INSERT INTO version (table_name, table_version) values
('rls_presentity','1');
  CREATE TABLE rls_presentity (
      id INT(10) UNSIGNED AUTO_INCREMENT PRIMARY KEY NOT NULL,
      rlsubs_did CHAR(255) NOT NULL,
      resource_uri CHAR(128) NOT NULL,
      content_type CHAR(64) NOT NULL,
      presence_state BLOB NOT NULL,
      expires INT(11) NOT NULL,
      updated INT(11) NOT NULL,
      auth_state INT(11) NOT NULL,
      reason CHAR(64) NOT NULL,
      CONSTRAINT rls_presentity_idx UNIQUE (rlsubs_did, resource_uri)
  ) ENGINE=MyISAM;
Again i got the same error.

Regards
rmnathan

----------------------------------------------------------------------

Comment By: Anca Vamanu (anca_vamanu)
Date: 2009-02-18 20:47

Message:
Hi Rmnathan,

Thank you for this report.
Indeed, you were right- not all update Notifies were sent due to a bug in
the code. I have fixed it. Please update to the new svn version and test it
yourself. I will wait for your feedback before closing this bug report.

regards,
Anca



----------------------------------------------------------------------

Comment By: Anca Vamanu (anca_vamanu)
Date: 2009-02-18 20:47

Message:
Hi Rmnathan,

Thank you for this report.
Indeed, you were right- not all update Notifies were sent due to a bug in
the code. I have fixed it. Please update to the new svn version and test it
yourself. I will wait for your feedback before closing this bug report.

regards,
Anca



----------------------------------------------------------------------

Comment By: Anca Vamanu (anca_vamanu)
Date: 2009-02-18 20:46

Message:
Hi Rmnathan,

Thank you for this report.
Indeed, you were right- not all update Notifies were sent due to a bug in
the code. I have fixed it. Please update to the new svn version and test it
yourself. I will wait for your feedback before closing this bug report.

regards,
Anca



----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=2591935&group_id=232389


From noreply at sourceforge.net  Fri Feb 27 13:06:29 2009
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 27 Feb 2009 12:06:29 +0000
Subject: [OpenSIPS-Devel] [ opensips-Bugs-2591935 ] Error in sending NOTIFY
	for PUBLISH in RLS mode
Message-ID: <E1Ld1U5-0005qT-Do@d55xhf1.ch3.sourceforge.com>

Bugs item #2591935, was opened at 2009-02-12 08:31
Message generated for change (Settings changed) made by anca_vamanu
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=2591935&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: Nathan (rmnathan)
Assigned to: Anca Vamanu (anca_vamanu)
Summary: Error in sending NOTIFY for PUBLISH in RLS mode

Initial Comment:
Hi
When opensips got publish for the user(say E1_1) which has in two list subscriptions, it is sending notify to one user only.
For example:
UE2_1 list will have 2 entry uri like E1_1,E1_2
UE2_2 list will have 2 entry uri like E1_2,E1_1

S2_1 subscribe to UE2_1
S2_2 subscribe to UE2_2
If E1_1 send publish, opensips sends notify to S2_1 only. But it should send notify to S2_2 too.

Please find the attached pcap file for detailed call flow.

Regards,
rmnathan


----------------------------------------------------------------------

Comment By: Nathan (rmnathan)
Date: 2009-02-27 13:24

Message:
Hi Anca,
This issue is fixed. 
Thanks a lot.

Regards,
rmnathan

----------------------------------------------------------------------

Comment By: Nathan (rmnathan)
Date: 2009-02-25 15:02

Message:
Hi Anca,
Thanks for your reply.
I can't understand one thing.

Step 1:
c3-1_list has two users as s3-1 and s3-2
c3-2_list has two users as s3-1 and s3-2

Step 2:
c3-1 subscribe to c3-1_list
c3-2 subscribe to c3-2_list

Step 3:
If RLS gets publish from s3-1
it is sending NOTIFY to c3-1 one only. It is not sending  NOTIFY to c3-2.
can u explain why it is not sending NOTIFY to c3-2.

My doubt is s3-1 is in both the lists (ie c3-1 and c3-2). But RLS sending
notify to c3-1 one only. It is not sending to c3-2.

Regards
rmnathan


 

----------------------------------------------------------------------

Comment By: Anca Vamanu (anca_vamanu)
Date: 2009-02-25 12:44

Message:
Hi Nathan,

I have looked in the trace and for me it looks perfectly ok.

I don't understand what you say is wrong.8.

 
   ' iii) from s3-1 to c3-1 this is not correct. it should send from s3-1
to c3-2 '

    You are referring to message number 65 ( or 71 which is a
retransmission of 65), right? And you what to say that the To header is
wrong? 
If this is true, then you are wrong. The To header is exactly the same as
in the initial Subscribe received from the proxy. Please do filter on
Call-ID and check this yourself.     
   
    'iV) from s3-2 to c3-2 this is not correct. it should send from s3-2
to c3-1'
The same here.

regards,
Anca



----------------------------------------------------------------------

Comment By: Nathan (rmnathan)
Date: 2009-02-24 17:19

Message:
Hi Anca,

For the same setup
Test setup details
IMS UE1 192.168.165.151:5070
IMS UE2 192.168.165.152:5075
Proxy - SCSCF (192.168.166.150:50602)
Opensips(presence server) (10.6.2.246:5060)
RLS (10.6.2.246:5060)

The difference is two users in the IMS UE1 users list

IMS UE1 has two users
1.c3-1 which has s3-1 in list

<?xml version="1.0" encoding="UTF-8"?>
 <rls-services>
 <service uri="sip:c3-1_list at 10.6.2.246">
   <list name="c3-1">
    <entry uri="sip:s3-1 at 10.6.2.246"/>
    <entry uri="sip:s3-2 at 10.6.2.246"/>
   </list>
   <packages>
    <package>presence</package>
   </packages>
  </service>


2.c3-2 which has also s3-1 in list

<?xml version="1.0" encoding="UTF-8"?>
 <rls-services>
 <service uri="sip:c3-2_list at 10.6.2.246">
   <list name="c3-2">
    <entry uri="sip:s3-1 at 10.6.2.246"/>
    <entry uri="sip:s3-2 at 10.6.2.246"/>
   </list>
   <packages>
    <package>presence</package>
   </packages>
  </service>
 </rls-services>


IMS UE2 has one user
1.s3-1 ( this is only to send publish)
2.s3-2 (this is only to send publish)

call flow description
=====================
1.IMS UE1 ie(c3-1 and c3-2) will send subcribe to their list
2. Presence server that receives the Subscribe messages sent by the rls
server for the list subscription because the users
  in the list are same domain of presence server. So RLS server sends
subscribe, 200 ok for subscribe , Notify and 200 ok
  for notify to presence server(ie to itself because opensips and RLS
server running on same IP: 10.6.2.246)
3. After got 200 ok for subscribe and notify  for IMS UE1 users
4. Send subscribe from IMS UE2 (ie s3-1 to c3-1 & s3-2 to c3-2) . This is
just to send publish.
5. Then send publish from s3-1 and s3-2  ie from IMS UE2.
6. After got publish RLS server should generate notify to c3-1 and c3-2
because c3-1 & c3-2 have subscribed to s3-1 and s3-2
7. From captured trace RLS server sends notify and 200 ok for notify to
presence server 
Analysis
=========
8. Then after that RLS sends notify to IMS UE1
    i) from s3-1 to c3-1
    ii) from s3-2 to c3-2
    iii) from s3-1 to c3-1 this is not correct. it should send from s3-1
to c3-2
    iV) from s3-2 to c3-2 this is not correct. it should send from s3-2 to
c3-1

Please find captured trace also.

Regards
rmnathan

----------------------------------------------------------------------

Comment By: Nathan (rmnathan)
Date: 2009-02-24 15:44

Message:
Hi,
Test setup details
IMS UE1 192.168.165.151:5070
IMS UE2  192.168.165.152:5075
Proxy - SCSCF (192.168.166.150:50602)
Opensips(presence server) (10.6.2.246:5060) 
RLS (10.6.2.246:5060)



----------------------------------------------------------------------

Comment By: Nathan (rmnathan)
Date: 2009-02-24 15:37

Message:
Hi Anca

Test setup description:
======================

IMS UE1
192.168.165.151:5070
				Proxy - SCSCF            ----  Opensips(presence server)   ---- RLS
server
			  (192.168.166.150:50602)	       (10.6.2.246:5060)               
(10.6.2.246:5060)
IMS UE2
192.168.165.152:5075


IMS UE1 has two users 
1.c3-1 which has s3-1 in list

<?xml version="1.0" encoding="UTF-8"?>
 <rls-services>
 <service uri="sip:c3-1_list at 10.6.2.246">
   <list name="c3-1">
    <entry uri="sip:s3-1 at 10.6.2.246"/>

   </list>
   <packages>
    <package>presence</package>
   </packages>
  </service>
 </rls-services>

2.c3-2 which has also s3-1 in list

<?xml version="1.0" encoding="UTF-8"?>
 <rls-services>
 <service uri="sip:c3-2_list at 10.6.2.246">
   <list name="c3-2">
    <entry uri="sip:s3-1 at 10.6.2.246"/>

   </list>
   <packages>
    <package>presence</package>
   </packages>
  </service>
 </rls-services>

IMS UE2 has one user
1.s3-1 ( this is only to send publish)


call flow description
=====================
1.IMS UE1 ie(c3-1 and c3-2) will send subcribe to their list
2. Presence server that receives the Subscribe messages sent by the rls
server for the list subscription because the users
  in the list are same domain of presence server. So RLS server sends
subscribe, 200 ok for subscribe , Notify and 200 ok
  for notify to presence server(ie to itself because opensips and RLS
server running on same IP: 10.6.2.246)
3. After got 200 ok for subscribe and notify  for IMS UE1 users
4. Send subscribe from IMS UE2 (ie s3-1 to c3-1) . This is just to send
publish.
5. Then send publish from s3-1 ie from IMS UE2. 
6. After got publish RLS server should generate notify to c3-1 and c3-2
because c3-1 & c3-2 have subscribed to s3-1 
7. From captured trace RLS server sends notify and 200 ok for notify to
presence server (please explain why this is sending notify to opensips)
8. Then after that RLS sends notify to IMS UE1

9. refreshed Publish from IMS UE2
10 Removed Publish  from IMS UE2


For your queries
================
do you use a presence server that receives the
Subscribe messages sent by the rls server and also Publish messages from
the clients?

yes presence server receives the subscribe messages sent by the rls
server. The publish from clients (in this case from s3-1 (IMS UE2)

2.you send the Subscribes directly to the clients and they
reply with Notifies?
No. the subscribes sends to presence server by the rls server.

Please let me know if you want more information.
Please find captured trace also.

Regards
rmnathan


----------------------------------------------------------------------

Comment By: Anca Vamanu (anca_vamanu)
Date: 2009-02-24 14:52

Message:
Hi Rmnathan,

If you really want to help me figure out what your problem is you have to
send simpler traces. Your trace is impossible to analize - you have 8 lists
with different names, but there are 4 pairs having the same content - so
there are actually only 4 unique lists. Then you use in 'From' header of
the SUBSCRIBE not the name of the list but anther uri - this is not
important in the SIP logic - but it makes impossible for me to follow the
messages since the Notifies that the RLS sends and receives will have the
same To and From headers.
Please if you want to help run a simpler case - only two Subscriptions to
lists that can have different names but the same content. 
One more question - do you use a presence server that receives the
Subscribe messages sent by the rls server and also Publish messages from
the clients? Or you send the Subscribes directly to the clients and they
reply with Notifies?
Please also include a description with the entities in the scenario and
the IP address and port they run at.

Thanks,
Anca


----------------------------------------------------------------------

Comment By: Anca Vamanu (anca_vamanu)
Date: 2009-02-24 13:29

Message:
Hi Rmnathan,

If you really want to help me figure out what your problem is you have to
send simpler traces. Your trace is impossible to analize - you have 8 lists
with different names, but there are 4 pairs having the same content - so
there are actually only 4 unique lists. Then you use in 'From' header of
the SUBSCRIBE not the name of the list but anther uri - this is not
important in the SIP logic - but it makes impossible for me to follow the
messages since the Notifies that the RLS sends and receives will have the
same To and From headers.
Please if you want to help run a simpler case - only two Subscriptions to
lists that can have different names but the same content. 
One more question - do you use a presence server that receives the
Subscribe messages sent by the rls server and also Publish messages from
the clients? Or you send the Subscribes directly to the clients and they
reply with Notifies?
Please also include a description with the entities in the scenario and
the IP address and port they run at.

Thanks,
Anca


----------------------------------------------------------------------

Comment By: Nathan (rmnathan)
Date: 2009-02-24 12:43

Message:
Hi Anca,
After that i have tested. still the issue is not fixed. Now opensips is
generating notify for all the users(for first user) in the list but it
always sending to first user in the list only not for other users. 

Please see the attached pcap file.

Regards
rmnathan



----------------------------------------------------------------------

Comment By: Anca Vamanu (anca_vamanu)
Date: 2009-02-24 11:49

Message:
Hi Rmnathan,

A change was made for many tables - changing varchar type to char and
since the structure was changed, the version of the tables was increased.
You need to get the new mysql script and recreate the table and also
update the version for rls_presentity table in 'version' table. However
since there are many tables for which the version was increased I would
recommend recreating the whole database.

regards,
Anca

----------------------------------------------------------------------

Comment By: Nathan (rmnathan)
Date: 2009-02-24 08:23

Message:
Hi Anca,
I tried with latest trunk 5354 build. while starting opensips i got
following error message
stinbng46:/usr/local/trunk# /usr/local/sbin/opensips
Listening on
             udp: 10.6.2.246 [10.6.2.246]:5060
Aliases:
             udp: stinbng46:5060

stinbng46:/usr/local/trunk# Feb 24 11:46:35 [2520]
ERROR:core:db_check_table_version: invalid version 0 for table
rls_presentity found, expected 1
Feb 24 11:46:35 [2520] ERROR:rls:mod_init: error during table version
check.
Feb 24 11:46:35 [2520] ERROR:core:init_mod: failed to initialize module
rls
Feb 24 11:46:35 [2520] ERROR:core:main: error while initializing modules
i have   rls_presentity table also in opensips database.
mysql> desc rls_presentity
    -> ;
+----------------+------------------+------+-----+---------+----------------+
| Field          | Type             | Null | Key | Default | Extra        
 |
+----------------+------------------+------+-----+---------+----------------+
| id             | int(10) unsigned | NO   | PRI | NULL    |
auto_increment |
| rlsubs_did     | char(255)        | NO   | MUL |         |              
 |
| resource_uri   | char(128)        | NO   |     |         |              
 |
| content_type   | char(64)         | NO   |     |         |              
 |
| presence_state | blob             | NO   |     |         |              
 |
| expires        | int(11)          | NO   |     |         |              
 |
| updated        | int(11)          | NO   | MUL |         |              
 |
| auth_state     | int(11)          | NO   |     |         |              
 |
| reason         | char(64)         | NO   |     |         |              
 |
+----------------+------------------+------+-----+---------+----------------+
9 rows in set (0.00 sec)

I have changed and tried table version in script also 
INSERT INTO version (table_name, table_version) values
('rls_presentity','1');
  CREATE TABLE rls_presentity (
      id INT(10) UNSIGNED AUTO_INCREMENT PRIMARY KEY NOT NULL,
      rlsubs_did CHAR(255) NOT NULL,
      resource_uri CHAR(128) NOT NULL,
      content_type CHAR(64) NOT NULL,
      presence_state BLOB NOT NULL,
      expires INT(11) NOT NULL,
      updated INT(11) NOT NULL,
      auth_state INT(11) NOT NULL,
      reason CHAR(64) NOT NULL,
      CONSTRAINT rls_presentity_idx UNIQUE (rlsubs_did, resource_uri)
  ) ENGINE=MyISAM;
Again i got the same error.

Regards
rmnathan

----------------------------------------------------------------------

Comment By: Anca Vamanu (anca_vamanu)
Date: 2009-02-18 17:17

Message:
Hi Rmnathan,

Thank you for this report.
Indeed, you were right- not all update Notifies were sent due to a bug in
the code. I have fixed it. Please update to the new svn version and test it
yourself. I will wait for your feedback before closing this bug report.

regards,
Anca



----------------------------------------------------------------------

Comment By: Anca Vamanu (anca_vamanu)
Date: 2009-02-18 17:17

Message:
Hi Rmnathan,

Thank you for this report.
Indeed, you were right- not all update Notifies were sent due to a bug in
the code. I have fixed it. Please update to the new svn version and test it
yourself. I will wait for your feedback before closing this bug report.

regards,
Anca



----------------------------------------------------------------------

Comment By: Anca Vamanu (anca_vamanu)
Date: 2009-02-18 17:16

Message:
Hi Rmnathan,

Thank you for this report.
Indeed, you were right- not all update Notifies were sent due to a bug in
the code. I have fixed it. Please update to the new svn version and test it
yourself. I will wait for your feedback before closing this bug report.

regards,
Anca



----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=2591935&group_id=232389


From noreply at sourceforge.net  Fri Feb 27 14:17:26 2009
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 27 Feb 2009 13:17:26 +0000
Subject: [OpenSIPS-Devel] [ opensips-Bugs-2636665 ] Bad parsing of BLOBs in
	db_postgres+patch
Message-ID: <E1Ld2ak-0004T6-Su@cdv4jf1.ch3.sourceforge.com>

Bugs item #2636665, was opened at 2009-02-25 13:53
Message generated for change (Comment added) made by krokodilerian
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=2636665&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: Vasil Kolev (krokodilerian)
Assigned to: Bogdan-Andrei Iancu (bogdan_iancu)
Summary: Bad parsing of BLOBs in db_postgres+patch

Initial Comment:
Excerpt from the logs:

Feb 25 11:09:20 [12106] DBG:db_postgres:db_postgres_submit_query: 0x8198488 PQsendQuery(select presentity_uri,expires,event,event_id,to_user,to_domain,watcher_username,watcher_domain,callid,to_tag,from_tag
,local_cseq,remote_cseq,record_route,socket_info,contact,local_contact,version,status,reason from active_watchers )
Feb 25 11:09:20 [12106] DBG:core:db_new_result: allocate 28 bytes for result set at 0x81984e8
Feb 25 11:09:20 [12106] DBG:db_postgres:db_postgres_fetch_result: 0x8198488 PQresultStatus(PGRES_TUPLES_OK) PQgetResult(0x9807030)
Feb 25 11:09:20 [12106] DBG:db_postgres:db_postgres_get_columns: 20 columns returned from the query
Feb 25 11:09:20 [12106] DBG:core:db_allocate_columns: allocate 320 bytes for result columns at 0x8198ae8
...
...
...
Feb 25 11:09:20 [12106] DBG:db_postgres:db_postgres_get_columns: RES_NAMES(0x8198bf0)[13]=[record_route]
Feb 25 11:09:20 [12106] DBG:db_postgres:db_postgres_get_columns: use DB_BLOB result type
...
...
...
Feb 25 11:09:20 [12106] DBG:db_postgres:db_postgres_convert_rows: allocated 0 bytes for row_buf[13] at 0x8198c88
Feb 25 11:09:20 [12106] DBG:db_postgres:db_postgres_convert_rows: [0][13] Column[record_route]=[]
...
...
...
Feb 25 11:09:20 [12106] DBG:db_postgres:db_postgres_str2val: converting BLOB []
Feb 25 11:09:20 [12106] DBG:db_postgres:db_postgres_str2val: got blob len 0
...
...
...
Feb 25 11:09:20 [12106] DBG:db_postgres:db_postgres_convert_rows: PQgetvalue(0x8198488,1,13)=[<98>!<F7><B7><98>!<F7><B7>^P]
Feb 25 11:09:20 [12106] DBG:db_postgres:db_postgres_convert_rows: allocated 9 bytes for row_buf[13] at 0x819a7a8

Patch should be self-explanatory :)

----------------------------------------------------------------------

>Comment By: Vasil Kolev (krokodilerian)
Date: 2009-02-27 15:17

Message:
Hi Bogdan,

On line 233 of res.c there's
len=strlen(s);

I think that if you just leave the len as it's set in the if() before
that, it would be better. I still am not sure if anything returned from
PQgetvalue() is required to be null-terminated, so just to be on the safe
side, I think taking 'len' from the database is the best choice.

----------------------------------------------------------------------

Comment By: Bogdan-Andrei Iancu (bogdan_iancu)
Date: 2009-02-26 12:18

Message:
Hi Vasil,

I applied the patch on SVN (1.4 and 1.5 vers), but slightly modified -
please update from SVN and test it - I want to be sure I haven't screwed up
something :).

Thanks and regards,
Bogdan

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=2636665&group_id=232389


From bogdan at voice-system.ro  Fri Feb 27 16:19:33 2009
From: bogdan at voice-system.ro (Bogdan-Andrei Iancu)
Date: Fri, 27 Feb 2009 15:19:33 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[5372]
	trunk/modules/db_postgres/res.c
Message-ID: <E1Ld4Uv-0003ac-U4@d5vjzd1.ch3.sourceforge.com>

Revision: 5372
          http://opensips.svn.sourceforge.net/opensips/?rev=5372&view=rev
Author:   bogdan_iancu
Date:     2009-02-27 15:19:33 +0000 (Fri, 27 Feb 2009)

Log Message:
-----------
- fix the blob len calculation - use the len from the DB driver.

Modified Paths:
--------------
    trunk/modules/db_postgres/res.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 Feb 27 16:19:40 2009
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 27 Feb 2009 15:19:40 +0000
Subject: [OpenSIPS-Devel] [ opensips-Bugs-2636665 ] Bad parsing of BLOBs in
	db_postgres+patch
Message-ID: <E1Ld4V2-0000kd-AQ@665xhf1.ch3.sourceforge.com>

Bugs item #2636665, was opened at 2009-02-25 13:53
Message generated for change (Comment added) made by bogdan_iancu
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=2636665&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: Vasil Kolev (krokodilerian)
Assigned to: Bogdan-Andrei Iancu (bogdan_iancu)
Summary: Bad parsing of BLOBs in db_postgres+patch

Initial Comment:
Excerpt from the logs:

Feb 25 11:09:20 [12106] DBG:db_postgres:db_postgres_submit_query: 0x8198488 PQsendQuery(select presentity_uri,expires,event,event_id,to_user,to_domain,watcher_username,watcher_domain,callid,to_tag,from_tag
,local_cseq,remote_cseq,record_route,socket_info,contact,local_contact,version,status,reason from active_watchers )
Feb 25 11:09:20 [12106] DBG:core:db_new_result: allocate 28 bytes for result set at 0x81984e8
Feb 25 11:09:20 [12106] DBG:db_postgres:db_postgres_fetch_result: 0x8198488 PQresultStatus(PGRES_TUPLES_OK) PQgetResult(0x9807030)
Feb 25 11:09:20 [12106] DBG:db_postgres:db_postgres_get_columns: 20 columns returned from the query
Feb 25 11:09:20 [12106] DBG:core:db_allocate_columns: allocate 320 bytes for result columns at 0x8198ae8
...
...
...
Feb 25 11:09:20 [12106] DBG:db_postgres:db_postgres_get_columns: RES_NAMES(0x8198bf0)[13]=[record_route]
Feb 25 11:09:20 [12106] DBG:db_postgres:db_postgres_get_columns: use DB_BLOB result type
...
...
...
Feb 25 11:09:20 [12106] DBG:db_postgres:db_postgres_convert_rows: allocated 0 bytes for row_buf[13] at 0x8198c88
Feb 25 11:09:20 [12106] DBG:db_postgres:db_postgres_convert_rows: [0][13] Column[record_route]=[]
...
...
...
Feb 25 11:09:20 [12106] DBG:db_postgres:db_postgres_str2val: converting BLOB []
Feb 25 11:09:20 [12106] DBG:db_postgres:db_postgres_str2val: got blob len 0
...
...
...
Feb 25 11:09:20 [12106] DBG:db_postgres:db_postgres_convert_rows: PQgetvalue(0x8198488,1,13)=[<98>!<F7><B7><98>!<F7><B7>^P]
Feb 25 11:09:20 [12106] DBG:db_postgres:db_postgres_convert_rows: allocated 9 bytes for row_buf[13] at 0x819a7a8

Patch should be self-explanatory :)

----------------------------------------------------------------------

>Comment By: Bogdan-Andrei Iancu (bogdan_iancu)
Date: 2009-02-27 17:19

Message:
OK - I made the change, could you check it again ?

Thanks and regards,
bogdan

----------------------------------------------------------------------

Comment By: Vasil Kolev (krokodilerian)
Date: 2009-02-27 15:17

Message:
Hi Bogdan,

On line 233 of res.c there's
len=strlen(s);

I think that if you just leave the len as it's set in the if() before
that, it would be better. I still am not sure if anything returned from
PQgetvalue() is required to be null-terminated, so just to be on the safe
side, I think taking 'len' from the database is the best choice.

----------------------------------------------------------------------

Comment By: Bogdan-Andrei Iancu (bogdan_iancu)
Date: 2009-02-26 12:18

Message:
Hi Vasil,

I applied the patch on SVN (1.4 and 1.5 vers), but slightly modified -
please update from SVN and test it - I want to be sure I haven't screwed up
something :).

Thanks and regards,
Bogdan

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=2636665&group_id=232389


From noreply at sourceforge.net  Fri Feb 27 16:31:36 2009
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 27 Feb 2009 15:31:36 +0000
Subject: [OpenSIPS-Devel] [ opensips-Bugs-2642701 ] Bug in db_postgres and
	BLOB handling+patch
Message-ID: <E1Ld4ga-0002y2-PQ@1bkjzd1.ch3.sourceforge.com>

Bugs item #2642701, was opened at 2009-02-26 20:30
Message generated for change (Settings changed) made by bogdan_iancu
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=2642701&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: Accepted
Priority: 5
Private: No
Submitted By: Vasil Kolev (krokodilerian)
>Assigned to: Bogdan-Andrei Iancu (bogdan_iancu)
Summary: Bug in db_postgres and BLOB handling+patch

Initial Comment:
After digging more in the db_postgres driver and problems with XML with appended characters, I looked into PGunescape (which is used on BLOB fields) and turns out it doesn't add NULL termination on the strings. It wouldn't be a problem if some other code didnt't rely on strlen() of such fields...

The NULL termination will always work, as PGunescape allocates one more byte for the field (to work around malloc(0)/realloc(0)).

Patch attached.

----------------------------------------------------------------------

Comment By: Vasil Kolev (krokodilerian)
Date: 2009-02-27 11:37

Message:
Bogdan, yes, it's the second part of the problem. With both patches the
issues with db_postgres should go away.

----------------------------------------------------------------------

Comment By: Bogdan-Andrei Iancu (bogdan_iancu)
Date: 2009-02-26 20:38

Message:
Vasil, is this related to 2636665 ?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=2642701&group_id=232389


From bogdan at voice-system.ro  Fri Feb 27 16:33:39 2009
From: bogdan at voice-system.ro (Bogdan-Andrei Iancu)
Date: Fri, 27 Feb 2009 15:33:39 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[5373]
	trunk/modules/db_postgres/val.c
Message-ID: <E1Ld4iZ-0004Eo-M1@d5vjzd1.ch3.sourceforge.com>

Revision: 5373
          http://opensips.svn.sourceforge.net/opensips/?rev=5373&view=rev
Author:   bogdan_iancu
Date:     2009-02-27 15:33:39 +0000 (Fri, 27 Feb 2009)

Log Message:
-----------
- I looked into PGunescape (which is used on BLOB fields) and turns out it doesn't add NULL termination on the strings. It wouldn't be a problem if some other code didnt't rely on strlen() of such fields...

Closes bug 2642701.
Credits go to Vasil Kolev.

Modified Paths:
--------------
    trunk/modules/db_postgres/val.c


This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site.


From bogdan at voice-system.ro  Fri Feb 27 16:37:13 2009
From: bogdan at voice-system.ro (Bogdan-Andrei Iancu)
Date: Fri, 27 Feb 2009 15:37:13 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[5374]
	branches/1.4/modules/db_postgres
Message-ID: <E1Ld4m1-0004In-QN@d5vjzd1.ch3.sourceforge.com>

Revision: 5374
          http://opensips.svn.sourceforge.net/opensips/?rev=5374&view=rev
Author:   bogdan_iancu
Date:     2009-02-27 15:37:13 +0000 (Fri, 27 Feb 2009)

Log Message:
-----------
backport from trunk (rev 5372 + 5372):

- fix the blob len calculation - use the len from the DB driver.

- I looked into PGunescape (which is used on BLOB fields) and turns out it doesn't add NULL termination on the strings. It wouldn't be a problem if some other code didnt't rely on strlen() of such fields...
Closes bug 2642701.
Credits go to Vasil Kolev.

Revision Links:
--------------
    http://opensips.svn.sourceforge.net/opensips/?rev=5372&view=rev

Modified Paths:
--------------
    branches/1.4/modules/db_postgres/res.c
    branches/1.4/modules/db_postgres/val.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 Feb 27 16:37:18 2009
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 27 Feb 2009 15:37:18 +0000
Subject: [OpenSIPS-Devel] [ opensips-Bugs-2642701 ] Bug in db_postgres and
	BLOB handling+patch
Message-ID: <E1Ld4m6-0003Th-Mk@d55xhf1.ch3.sourceforge.com>

Bugs item #2642701, was opened at 2009-02-26 20:30
Message generated for change (Comment added) made by bogdan_iancu
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=2642701&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: Vasil Kolev (krokodilerian)
Assigned to: Bogdan-Andrei Iancu (bogdan_iancu)
Summary: Bug in db_postgres and BLOB handling+patch

Initial Comment:
After digging more in the db_postgres driver and problems with XML with appended characters, I looked into PGunescape (which is used on BLOB fields) and turns out it doesn't add NULL termination on the strings. It wouldn't be a problem if some other code didnt't rely on strlen() of such fields...

The NULL termination will always work, as PGunescape allocates one more byte for the field (to work around malloc(0)/realloc(0)).

Patch attached.

----------------------------------------------------------------------

>Comment By: Bogdan-Andrei Iancu (bogdan_iancu)
Date: 2009-02-27 17:37

Message:
Applied on 1.4 and 1.5.

Thanks and regards,
Bogdan

----------------------------------------------------------------------

Comment By: Vasil Kolev (krokodilerian)
Date: 2009-02-27 11:37

Message:
Bogdan, yes, it's the second part of the problem. With both patches the
issues with db_postgres should go away.

----------------------------------------------------------------------

Comment By: Bogdan-Andrei Iancu (bogdan_iancu)
Date: 2009-02-26 20:38

Message:
Vasil, is this related to 2636665 ?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=2642701&group_id=232389


From noreply at sourceforge.net  Fri Feb 27 16:46:15 2009
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 27 Feb 2009 15:46:15 +0000
Subject: [OpenSIPS-Devel] [ opensips-Bugs-2641464 ] engage_media_proxy
	failes if called after create_dialog
Message-ID: <E1Ld4ul-0005jt-F7@d45xhf1.ch3.sourceforge.com>

Bugs item #2641464, was opened at 2009-02-26 14:16
Message generated for change (Comment added) made by bogdan_iancu
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=2641464&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: Thomas Gelf (thomas_gelf)
Assigned to: Nobody/Anonymous (nobody)
Summary: engage_media_proxy failes if called after create_dialog

Initial Comment:
If I correctly understood mediaproxy.c it installs a callback handler __dialog_created, responsible for setting up the other handlers for this dialog (using dlg_api.register_dlgcb).

However, if you called create_dialog() before, "dialog_created" will not be fired again if you are using engage_media_proxy().

Proposed solution: either add a note to current documentation ("...do NOT use create_dialog when using engage_media_proxy...") or find a way to catch this situation in EngageMediaProxy (maybe: if dlg started, immediately register dialog callbacks).

Best regards,
Thomas Gelf


----------------------------------------------------------------------

>Comment By: Bogdan-Andrei Iancu (bogdan_iancu)
Date: 2009-02-27 17:46

Message:
But when calling the create_dialog() function, the dialog module is
automatically triggering the dialog_created callback.
Internally there is the same function tiggered by flag setting or by the
create function.

Maybe the engage_media_proxy() is expecting to have the dialog created
later and it is doing some other stuff before.

Regards,
Bogdan

----------------------------------------------------------------------

Comment By: Dan (dan_pascu)
Date: 2009-02-27 12:48

Message:
I think that the dialog module should immediately trigger the registered
callback for create dialog, if the dialog was created before that point.
This is the most obvious thing to do, as the code using the dialog module
will not have to be aware of the internal details of the dialog module and
its state, nor will it need to inspect the dialog module to figure out what
to do next.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=2641464&group_id=232389


From noreply at sourceforge.net  Fri Feb 27 17:00:05 2009
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 27 Feb 2009 16:00:05 +0000
Subject: [OpenSIPS-Devel] [ opensips-Bugs-2641453 ] Latest 1.5 trunk Debian
	packaging "make deb" fails
Message-ID: <E1Ld589-0006ec-N8@d45xhf1.ch3.sourceforge.com>

Bugs item #2641453, was opened at 2009-02-26 14:13
Message generated for change (Comment added) made by bogdan_iancu
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=2641453&group_id=232389

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: packaging
Group: trunk
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Alex Massover (cupotka2008)
>Assigned to: Bogdan-Andrei Iancu (bogdan_iancu)
Summary: Latest 1.5 trunk Debian packaging "make deb" fails

Initial Comment:
Hi!

Debian packaging ("make deb") fails on latest trunk:

dpatch  apply-all  
applying patch 10_no_lib64_on_64_bits to ./ ... failed.
make[1]: *** [patch-stamp] Error 1
make[1]: Leaving directory `/tmp/opensips_head'
dpkg-buildpackage: failure: debian/rules build gave error exit status 2
make: *** [deb] Error 2

Best Regards,
Alex.




----------------------------------------------------------------------

>Comment By: Bogdan-Andrei Iancu (bogdan_iancu)
Date: 2009-02-27 18:00

Message:
Alex,

Can you check again ? be mistake I uploaded on SVN the Makefile with the
deb patches already applied, so of course, the re-patching was failing.

Update and try again.

Regards,
Bogdan

----------------------------------------------------------------------

Comment By: Thomas Gelf (thomas_gelf)
Date: 2009-02-26 15:15

Message:
To say it like Obama: YES I CAN ;-)
As long as I don't run "make deb" nobody removes my debian folder /
symlink (I'm keeping my personal one as I want each build to get it's own
version number) and svn update && dpkg-buildpackage succeeds.

I tried a fresh new checkout, make deb fails. And I can confirm your
failfailsucceed behaviour, same thing here.


----------------------------------------------------------------------

Comment By: Alex Massover (cupotka2008)
Date: 2009-02-26 14:50

Message:
There's a difference. You can't run dpkg-buildpackage on new clean
downloaded trunk. /debian directory is created by "make deb".
I happens like following:

1. First "make deb" on clean svn gives:

dpatch  apply-all  
applying patch 10_no_lib64_on_64_bits to ./ ... failed.
make[1]: *** [patch-stamp] Error 1
make[1]: Leaving directory `/tmp/opensips_head'
dpkg-buildpackage: failure: debian/rules build gave error exit status 2
make: *** [deb] Error 2

2. After if I run dpkg-buildpackage it gives:

 debian/rules build
test -d debian/patched || install -d debian/patched
dpatch  apply-all  
applying patch 10_no_lib64_on_64_bits to ./ ... ok.
applying patch 11_always_smp to ./ ... failed.
make: *** [patch-stamp] Error 1

10_no_lib64_on_64_bits patch already ok, but still 11_always_smp fails.

3. One more time dpkg-buildpackage:

 debian/rules build
test -d debian/patched || install -d debian/patched
dpatch  apply-all  
applying patch 10_no_lib64_on_64_bits to ./ ... ok.
applying patch 11_always_smp to ./ ... ok.
dpatch  cat-all  >>patch-stampT

This run is already OK.

Looks like 3 tries of patching/depatching makes a trick.  

----------------------------------------------------------------------

Comment By: Thomas Gelf (thomas_gelf)
Date: 2009-02-26 14:27

Message:
Hmmm... I've created packages from trunk 30 minutes ago, without any issue
(using dpkg-buildpackage, not make deb - but this shouldn't make any
difference).

Platform: Debian Lenny, 64bit.

Cheers,
Thomas Gelf


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=2641453&group_id=232389


From noreply at sourceforge.net  Fri Feb 27 17:01:28 2009
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 27 Feb 2009 16:01:28 +0000
Subject: [OpenSIPS-Devel] [ opensips-Bugs-2627561 ] auth_radius: allow
	sip-avps to be passed for rejected reques
Message-ID: <E1Ld59U-0000Bu-4Z@b55xhf1.ch3.sourceforge.com>

Bugs item #2627561, was opened at 2009-02-22 14:09
Message generated for change (Comment added) made by bogdan_iancu
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=2627561&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: Alex Massover (cupotka2008)
Assigned to: Bogdan-Andrei Iancu (bogdan_iancu)
Summary: auth_radius: allow sip-avps to be passed for rejected reques

Initial Comment:
Hi!

This simple patch for auth_radius module allows to pass additional credentials (sip-avps) also for rejected radius requests. For example it can be used for passing custom error codes.

Best Regards,
Alex Massover.

----------------------------------------------------------------------

>Comment By: Bogdan-Andrei Iancu (bogdan_iancu)
Date: 2009-02-27 18:01

Message:
So it should be fine. I will do the backport to 1.4 also.

Thanks and regards,
Bogdan

----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2009-02-26 13:17

Message:
Hi!

The following one is working for me for 1.3.2. I'm starting migration to
1.5, and will test it also.

} else {
                LM_ERR("rc_auth failed\n");
                if (received) generate_avps(received);
                goto err;
        }


----------------------------------------------------------------------

Comment By: Bogdan-Andrei Iancu (bogdan_iancu)
Date: 2009-02-26 13:00

Message:
Alex,

I applied the patch on 1.5 - I did some small change to try to get the AVP
from a the RADIUS reply (if valid) disregarding the reply code. Could you
please overview and confirm if ok?

I'm waiting for your confirmation before backporting to 1.4

Regards,
Bogdan

----------------------------------------------------------------------

Comment By: Bogdan-Andrei Iancu (bogdan_iancu)
Date: 2009-02-24 16:36

Message:
Hi Alex,

Thanks - this is more like a bug, so I moved it accordingly. I will
shortly overview and commit it.

Regards,
Bogdan

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=2627561&group_id=232389


From bogdan at voice-system.ro  Fri Feb 27 17:06:43 2009
From: bogdan at voice-system.ro (Bogdan-Andrei Iancu)
Date: Fri, 27 Feb 2009 16:06:43 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[5375]
	branches/1.4/modules/auth_radius/sterman.c
Message-ID: <E1Ld5EZ-000157-20@dn4whf1.ch3.sourceforge.com>

Revision: 5375
          http://opensips.svn.sourceforge.net/opensips/?rev=5375&view=rev
Author:   bogdan_iancu
Date:     2009-02-27 16:06:42 +0000 (Fri, 27 Feb 2009)

Log Message:
-----------
backport from trunk (rev #5370):
-fixed fetching of returned AVPS in RADIUS reply.
 
 Closes bug #2627561
 Credits go to Alex Massover.

Revision Links:
--------------
    http://opensips.svn.sourceforge.net/opensips/?rev=5370&view=rev

Modified Paths:
--------------
    branches/1.4/modules/auth_radius/sterman.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 Feb 27 17:13:46 2009
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 27 Feb 2009 16:13:46 +0000
Subject: [OpenSIPS-Devel] [ opensips-Patches-2621299 ] Enhance MySQL prepare
	statment diagnostics
Message-ID: <E1Ld5LO-0004VT-Q5@665xhf1.ch3.sourceforge.com>

Patches item #2621299, was opened at 2009-02-20 23:15
Message generated for change (Comment added) made by bogdan_iancu
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086412&aid=2621299&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: Rejected
Priority: 5
Private: No
Submitted By: Norm Brandinger (norm_brandinger)
>Assigned to: Bogdan-Andrei Iancu (bogdan_iancu)
Summary: Enhance MySQL prepare statment diagnostics

Initial Comment:
Enhance the diagnostics produced then the mysql_stmt_prepare() function fails.

For example, the unknown column that caused the failure is now provided.

ERROR:db_mysql:get_new_stmt_ctx: mysql_stmt_prepare() failed: Unknown column 'bad_column' in 'field list'

----------------------------------------------------------------------

>Comment By: Bogdan-Andrei Iancu (bogdan_iancu)
Date: 2009-02-27 18:13

Message:
Hi Norm,

I think the way you get the error code is not correct. The
mysql_stmt_execute() function does not return the err code, but only an err
indication. To get the err code you need to use mysql_stmt_errno(). See:
     http://dev.mysql.com/doc/refman/5.0/en/mysql-stmt-execute.html

Regards,
Bogdan

----------------------------------------------------------------------

Comment By: Norm Brandinger (norm_brandinger)
Date: 2009-02-23 15:27

Message:
Updated the patch to add the enhanced diagnostic output for both prepare
statements located in the dbase.c file.  The original patch only updated
the first prepare statement.
File Added: dbase.c.patch2

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086412&aid=2621299&group_id=232389


From bogdan at voice-system.ro  Fri Feb 27 18:19:10 2009
From: bogdan at voice-system.ro (Bogdan-Andrei Iancu)
Date: Fri, 27 Feb 2009 17:19:10 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[5376]
	trunk/modules/avpops/avpops_db.c
Message-ID: <E1Ld6Mg-0000g7-Rc@74yxhf1.ch3.sourceforge.com>

Revision: 5376
          http://opensips.svn.sourceforge.net/opensips/?rev=5376&view=rev
Author:   bogdan_iancu
Date:     2009-02-27 17:19:10 +0000 (Fri, 27 Feb 2009)

Log Message:
-----------
- fixed shutdown (if err) cleanup

Modified Paths:
--------------
    trunk/modules/avpops/avpops_db.c


This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site.


From bogdan at voice-system.ro  Fri Feb 27 20:30:20 2009
From: bogdan at voice-system.ro (Bogdan-Andrei Iancu)
Date: Fri, 27 Feb 2009 19:30:20 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[5377]
	trunk/modules/db_mysql/dbase.c
Message-ID: <E1Ld8Pc-0004Vo-7j@74yxhf1.ch3.sourceforge.com>

Revision: 5377
          http://opensips.svn.sourceforge.net/opensips/?rev=5377&view=rev
Author:   bogdan_iancu
Date:     2009-02-27 19:30:19 +0000 (Fri, 27 Feb 2009)

Log Message:
-----------
- improved the detection of mysql server disconnection -> re-init the statements.
- ugly workarond for new libmysqlsclient where getting the err code does not work (at least now) and we need to rely on the error text message.

Part of bug 2608188

Modified Paths:
--------------
    trunk/modules/db_mysql/dbase.c


This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site.


From bogdan at voice-system.ro  Fri Feb 27 20:57:44 2009
From: bogdan at voice-system.ro (Bogdan-Andrei Iancu)
Date: Fri, 27 Feb 2009 19:57:44 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[5378] trunk/Makefile
Message-ID: <E1Ld8q8-0006hU-I2@c3vjzd1.ch3.sourceforge.com>

Revision: 5378
          http://opensips.svn.sourceforge.net/opensips/?rev=5378&view=rev
Author:   bogdan_iancu
Date:     2009-02-27 19:57:44 +0000 (Fri, 27 Feb 2009)

Log Message:
-----------
- exclude from compile xml2 lib dependent modules

Modified Paths:
--------------
    trunk/Makefile


This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site.


From bogdan at voice-system.ro  Fri Feb 27 21:52:55 2009
From: bogdan at voice-system.ro (Bogdan-Andrei Iancu)
Date: Fri, 27 Feb 2009 20:52:55 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[5379]
	trunk/modules/regex/Makefile
Message-ID: <E1Ld9hX-0007ZB-6F@3kljzd1.ch3.sourceforge.com>

Revision: 5379
          http://opensips.svn.sourceforge.net/opensips/?rev=5379&view=rev
Author:   bogdan_iancu
Date:     2009-02-27 20:52:54 +0000 (Fri, 27 Feb 2009)

Log Message:
-----------
- just identation

Modified Paths:
--------------
    trunk/modules/regex/Makefile


This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site.


From bogdan at voice-system.ro  Fri Feb 27 21:53:39 2009
From: bogdan at voice-system.ro (Bogdan-Andrei Iancu)
Date: Fri, 27 Feb 2009 20:53:39 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[5380]
	trunk/modules/auth_radius/sterman.c
Message-ID: <E1Ld9iF-0007Zw-KY@3kljzd1.ch3.sourceforge.com>

Revision: 5380
          http://opensips.svn.sourceforge.net/opensips/?rev=5380&view=rev
Author:   bogdan_iancu
Date:     2009-02-27 20:53:39 +0000 (Fri, 27 Feb 2009)

Log Message:
-----------
- identation again

Modified Paths:
--------------
    trunk/modules/auth_radius/sterman.c


This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site.


From bogdan at voice-system.ro  Fri Feb 27 22:01:41 2009
From: bogdan at voice-system.ro (Bogdan-Andrei Iancu)
Date: Fri, 27 Feb 2009 21:01:41 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[5381]
	trunk/modules/db_mysql/dbase.c
Message-ID: <E1Ld9q1-0007jn-4w@3kljzd1.ch3.sourceforge.com>

Revision: 5381
          http://opensips.svn.sourceforge.net/opensips/?rev=5381&view=rev
Author:   bogdan_iancu
Date:     2009-02-27 21:01:40 +0000 (Fri, 27 Feb 2009)

Log Message:
-----------
- Enhance the diagnostics produced then the mysql_stmt_prepare() function fails.

Closes patch 2621299.
Credits go to Norm Brandinger.

Modified Paths:
--------------
    trunk/modules/db_mysql/dbase.c


This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site.


From noreply at sourceforge.net  Fri Feb 27 22:02:54 2009
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 27 Feb 2009 21:02:54 +0000
Subject: [OpenSIPS-Devel] [ opensips-Patches-2621299 ] Enhance MySQL prepare
	statment diagnostics
Message-ID: <E1Ld9rC-0003dS-0R@d45xhf1.ch3.sourceforge.com>

Patches item #2621299, was opened at 2009-02-20 23:15
Message generated for change (Comment added) made by bogdan_iancu
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086412&aid=2621299&group_id=232389

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: modules
Group: trunk
>Status: Closed
>Resolution: Accepted
Priority: 5
Private: No
Submitted By: Norm Brandinger (norm_brandinger)
Assigned to: Bogdan-Andrei Iancu (bogdan_iancu)
Summary: Enhance MySQL prepare statment diagnostics

Initial Comment:
Enhance the diagnostics produced then the mysql_stmt_prepare() function fails.

For example, the unknown column that caused the failure is now provided.

ERROR:db_mysql:get_new_stmt_ctx: mysql_stmt_prepare() failed: Unknown column 'bad_column' in 'field list'

----------------------------------------------------------------------

>Comment By: Bogdan-Andrei Iancu (bogdan_iancu)
Date: 2009-02-27 23:02

Message:
ok - following the IRC (#opensips) discussion, the patch was adopted in a
different version.

Thanks Norm for the research.

Regards,
Bogdan



----------------------------------------------------------------------

Comment By: Bogdan-Andrei Iancu (bogdan_iancu)
Date: 2009-02-27 18:13

Message:
Hi Norm,

I think the way you get the error code is not correct. The
mysql_stmt_execute() function does not return the err code, but only an err
indication. To get the err code you need to use mysql_stmt_errno(). See:
     http://dev.mysql.com/doc/refman/5.0/en/mysql-stmt-execute.html

Regards,
Bogdan

----------------------------------------------------------------------

Comment By: Norm Brandinger (norm_brandinger)
Date: 2009-02-23 15:27

Message:
Updated the patch to add the enhanced diagnostic output for both prepare
statements located in the dbase.c file.  The original patch only updated
the first prepare statement.
File Added: dbase.c.patch2

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086412&aid=2621299&group_id=232389


From noreply at sourceforge.net  Fri Feb 27 22:03:36 2009
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 27 Feb 2009 21:03:36 +0000
Subject: [OpenSIPS-Devel] [ opensips-Bugs-2608188 ] OpenSIPS latest trunk
	libmysqlclient segfault
Message-ID: <E1Ld9rs-0003H4-EM@g45xhf1.ch3.sourceforge.com>

Bugs item #2608188, was opened at 2009-02-17 08:02
Message generated for change (Comment added) made by bogdan_iancu
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=2608188&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: 9
Private: No
Submitted By: Om Bikram Thapa (omthapa)
Assigned to: Bogdan-Andrei Iancu (bogdan_iancu)
Summary: OpenSIPS latest trunk libmysqlclient segfault 

Initial Comment:
OpenSIPS latest trunk on Debian Lenny/AMD64 dies with libmysqlclient segfault after a MySQL restart. The event that triggers this crash is registration related database query immediately after a MySQL restart. Once OpenSIPS is restarted after a crash, everything runs fine until next MySQL restart.

The log shows:

"opensips[16769]: segfault at 4c8 ip 7f36728bf283 sp 7fff7ba11a90 error 4 in libmysqlclient.so.15.0.0[7f3672862000+1bf000]"
 
and gdb bt gives following results:

---------------
Program terminated with signal 11, Segmentation fault.
[New process 16769]
#0  0x00007f36728bf283 in mysql_stmt_result_metadata ()
   from /usr/lib/libmysqlclient.so.15
(gdb) bt
#0  0x00007f36728bf283 in mysql_stmt_result_metadata ()
   from /usr/lib/libmysqlclient.so.15
#1  0x00007f3672c707b7 in db_mysql_do_prepared_query (conn=0x78b278, 
    query=<value optimized out>, v=0x7fff7ba11d20, n=1, uv=0x0, un=0)
    at dbase.c:363
#2  0x00007f3672c72e1f in db_mysql_query (_h=0x78b278, 
    _k=<value optimized out>, _op=<value optimized out>, _v=0x7fff7ba11d20, 
    _c=<value optimized out>, _n=1, _nc=2, _o=0x0, _r=0x7fff7ba11dc0)
    at dbase.c:591
#3  0x00007f366f3f0398 in authorize (_m=0x78fe98, 
    _realm=<value optimized out>, _table=<value optimized out>, 
    _hftype=<value optimized out>) at authorize.c:107
#4  0x000000000040f869 in do_action (a=0x780a48, msg=0x78fe98) at action.c:961
#5  0x000000000040e7e5 in run_action_list (a=<value optimized out>, 
    msg=0x78fe98) at action.c:139
#6  0x000000000046f194 in eval_elem (e=0x780b18, msg=0x78fe98, val=0x0)
    at route.c:1189
#7  0x00000000004708ed in eval_expr (e=0x120b1e0, msg=0x78fe98, val=0x0)
    at route.c:1486
#8  0x000000000047089c in eval_expr (e=0x780b60, msg=0x78fe98, val=0x0)
    at route.c:1502
#9  0x00000000004708c5 in eval_expr (e=0x780ba8, msg=0x78fe98, val=0x0)
    at route.c:1507
---Type <return> to continue, or q <return> to quit---
#10 0x000000000040f91c in do_action (a=0x780f40, msg=0x78fe98) at action.c:688
#11 0x000000000040e7e5 in run_action_list (a=<value optimized out>, 
    msg=0x78fe98) at action.c:139
#12 0x00000000004114d3 in do_action (a=0x781eb0, msg=0x78fe98) at action.c:705
#13 0x000000000040e7e5 in run_action_list (a=<value optimized out>, 
    msg=0x78fe98) at action.c:139
#14 0x0000000000410e07 in do_action (a=0x77ee88, msg=0x78fe98) at action.c:119
#15 0x000000000040e7e5 in run_action_list (a=<value optimized out>, 
    msg=0x78fe98) at action.c:139
#16 0x00000000004114d3 in do_action (a=0x77f028, msg=0x78fe98) at action.c:705
#17 0x000000000040e7e5 in run_action_list (a=<value optimized out>, 
    msg=0x78fe98) at action.c:139
#18 0x00000000004125fe in run_top_route (a=0x777e78, msg=0x78fe98)
    at action.c:119
#19 0x000000000045e898 in receive_msg (
    buf=0x749180 "REGISTER sip:x.x.x.x SIP/2.0\r\nCSeq: 2 REGISTER\r\nVia: SIP/2.0/UDP x.x.x.x:5061;branch=z9hG4bK60f1b2dd-57fa-dd11-9401-0015c5404858;rport\r\nUser-Agent: Ekiga/2.0.12\r\nAuthorization: Dige"..., 
    len=749, rcv_info=0x7fff7ba13530) at receive.c:165
#20 0x000000000049d3a6 in udp_rcv_loop () at udp_server.c:449
#21 0x00000000004291fb in main (argc=<value optimized out>, 
    argv=0x7fff7ba13718) at main.c:778
----------------


----------------------------------------------------------------------

>Comment By: Bogdan-Andrei Iancu (bogdan_iancu)
Date: 2009-02-27 23:03

Message:
OK - a new fix is available on SVN.

Please test.

Regards,
Bogdan

----------------------------------------------------------------------

Comment By: Norm Brandinger (norm_brandinger)
Date: 2009-02-20 23:09

Message:
Sorry, my problem was self-inflicted.

----------------------------------------------------------------------

Comment By: Norm Brandinger (norm_brandinger)
Date: 2009-02-20 22:37

Message:
Although this isn't a segfault, it's likely that fixing one MySQL problem
will fix others.  Below is the result of a fresh install on a newly
formatted system (debian 2.6.26-1-amd64) and the latest OpenSIPS trunk:

DBG:db_mysql:db_mysql_do_prepared_query: new query=|select
password,account_id from subscriber where username=?|
ERROR:db_mysql:get_new_stmt_ctx: failed while mysql_stmt_prepare()
ERROR:db_mysql:db_mysql_do_prepared_query: failed to create new context
ERROR:auth_db:get_ha1: failed to query database


----------------------------------------------------------------------

Comment By: I?aki Baz (ibc_sf)
Date: 2009-02-20 12:46

Message:
My OpenSIPS rev-5351 crahses daily without restarting MySQL (Debian Etch 64
bits). Simple backtrace:

#0  0x00002b1cd7475a92 in mysql_stmt_result_metadata () from
/usr/lib/libmysqlclient.so.15
#1  0x00002b1cd730023c in db_mysql_free_result () from
/usr/lib/opensips/modules/db_mysql.so
#2  0x00002b1cd73013b6 in db_mysql_query () from
/usr/lib/opensips/modules/db_mysql.so
#3  0x00002b1cd859b8f8 in ?? () from /usr/lib/opensips/modules/auth_db.so
#4  0x000000000040f894 in do_action ()
#5  0x000000000040e0f3 in run_action_list ()
#6  0x000000000044c957 in eval_expr ()
#7  0x000000000044c3d0 in eval_expr ()
#8  0x000000000044c34f in eval_expr ()
#9  0x000000000040f939 in do_action ()
#10 0x000000000040e0f3 in run_action_list ()
#11 0x000000000041093a in do_action ()
#12 0x000000000040e0f3 in run_action_list ()
#13 0x000000000041176f in do_action ()
#14 0x000000000040e0f3 in run_action_list ()
#15 0x000000000040e480 in run_top_route ()
#16 0x0000000000441b4c in receive_msg ()
#17 0x0000000000464bfd in tcp_read_req ()
#18 0x000000000046691e in tcp_read_req ()
#19 0x0000000000468114 in tcp_receive_loop ()
#20 0x000000000045b83d in tcp_init_children ()
#21 0x000000000042368e in main ()


----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2009-02-19 08:56

Message:
Hi Bogdan,

The issue remains with latest SVN also.

Here is the gdb trace now:

#0  0x00007f0119426283 in mysql_stmt_result_metadata () from
/usr/lib/libmysqlclient.so.15
(gdb) bt
#0  0x00007f0119426283 in mysql_stmt_result_metadata () from
/usr/lib/libmysqlclient.so.15
#1  0x00007f01197d8f82 in db_mysql_do_prepared_query (conn=0x78b278,
query=<value optimized out>, v=0x7fff22576880, n=<value optimized out>,
uv=0x0, un=0)
    at dbase.c:368
#2  0x00007f01197daccd in db_mysql_query (_h=0x78b278, _k=<value optimized
out>, _op=<value optimized out>, _v=0x7fff22576880, _c=<value optimized
out>, 
    _n=1, _nc=2, _o=0x0, _r=0x7fff22576920) at dbase.c:603
#3  0x00007f0115f56398 in authorize (_m=0x78fe98, _realm=<value optimized
out>, _table=<value optimized out>, _hftype=<value optimized out>)
    at authorize.c:107
#4  0x000000000040f869 in do_action (a=0x780a48, msg=0x78fe98) at
action.c:961
#5  0x000000000040e7e5 in run_action_list (a=<value optimized out>,
msg=0x78fe98) at action.c:139
#6  0x000000000046f194 in eval_elem (e=0x780b18, msg=0x78fe98, val=0x0) at
route.c:1189
#7  0x00000000004708ed in eval_expr (e=0x27648e0, msg=0x78fe98, val=0x0)
at route.c:1486
#8  0x000000000047089c in eval_expr (e=0x780b60, msg=0x78fe98, val=0x0) at
route.c:1502
#9  0x00000000004708c5 in eval_expr (e=0x780ba8, msg=0x78fe98, val=0x0) at
route.c:1507
#10 0x000000000040f91c in do_action (a=0x780f40, msg=0x78fe98) at
action.c:688
#11 0x000000000040e7e5 in run_action_list (a=<value optimized out>,
msg=0x78fe98) at action.c:139
#12 0x00000000004114d3 in do_action (a=0x781eb0, msg=0x78fe98) at
action.c:705
#13 0x000000000040e7e5 in run_action_list (a=<value optimized out>,
msg=0x78fe98) at action.c:139
#14 0x0000000000410e07 in do_action (a=0x77ee88, msg=0x78fe98) at
action.c:119
#15 0x000000000040e7e5 in run_action_list (a=<value optimized out>,
msg=0x78fe98) at action.c:139
#16 0x00000000004114d3 in do_action (a=0x77f028, msg=0x78fe98) at
action.c:705
#17 0x000000000040e7e5 in run_action_list (a=<value optimized out>,
msg=0x78fe98) at action.c:139
#18 0x00000000004125fe in run_top_route (a=0x777e78, msg=0x78fe98) at
action.c:119
#19 0x000000000045e898 in receive_msg (
    buf=0x749180 "REGISTER sip:x.x.x.x SIP/2.0\r\nCSeq: 58
REGISTER\r\nVia: SIP/2.0/UDP
x.x.x.x:5068;branch=z9hG4bK5ca4685b-befc-dd11-911f-0015c5404858;rport\r\nUser-Agent:
Ekiga/2.0.12\r\nAuthorization: Dig"..., len=750, rcv_info=0x7fff22578090)
at receive.c:165
#20 0x000000000049d3a6 in udp_rcv_loop () at udp_server.c:449
#21 0x00000000004291fb in main (argc=<value optimized out>,
argv=0x7fff22578278) at main.c:778


----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2009-02-19 08:52

Message:
Hi Bogdan,

The issue remains with latest SVN also.

Here is the gdb trace now:

#0  0x00007f0119426283 in mysql_stmt_result_metadata () from
/usr/lib/libmysqlclient.so.15
(gdb) bt
#0  0x00007f0119426283 in mysql_stmt_result_metadata () from
/usr/lib/libmysqlclient.so.15
#1  0x00007f01197d8f82 in db_mysql_do_prepared_query (conn=0x78b278,
query=<value optimized out>, v=0x7fff22576880, n=<value optimized out>,
uv=0x0, un=0)
    at dbase.c:368
#2  0x00007f01197daccd in db_mysql_query (_h=0x78b278, _k=<value optimized
out>, _op=<value optimized out>, _v=0x7fff22576880, _c=<value optimized
out>, 
    _n=1, _nc=2, _o=0x0, _r=0x7fff22576920) at dbase.c:603
#3  0x00007f0115f56398 in authorize (_m=0x78fe98, _realm=<value optimized
out>, _table=<value optimized out>, _hftype=<value optimized out>)
    at authorize.c:107
#4  0x000000000040f869 in do_action (a=0x780a48, msg=0x78fe98) at
action.c:961
#5  0x000000000040e7e5 in run_action_list (a=<value optimized out>,
msg=0x78fe98) at action.c:139
#6  0x000000000046f194 in eval_elem (e=0x780b18, msg=0x78fe98, val=0x0) at
route.c:1189
#7  0x00000000004708ed in eval_expr (e=0x27648e0, msg=0x78fe98, val=0x0)
at route.c:1486
#8  0x000000000047089c in eval_expr (e=0x780b60, msg=0x78fe98, val=0x0) at
route.c:1502
#9  0x00000000004708c5 in eval_expr (e=0x780ba8, msg=0x78fe98, val=0x0) at
route.c:1507
#10 0x000000000040f91c in do_action (a=0x780f40, msg=0x78fe98) at
action.c:688
#11 0x000000000040e7e5 in run_action_list (a=<value optimized out>,
msg=0x78fe98) at action.c:139
#12 0x00000000004114d3 in do_action (a=0x781eb0, msg=0x78fe98) at
action.c:705
#13 0x000000000040e7e5 in run_action_list (a=<value optimized out>,
msg=0x78fe98) at action.c:139
#14 0x0000000000410e07 in do_action (a=0x77ee88, msg=0x78fe98) at
action.c:119
#15 0x000000000040e7e5 in run_action_list (a=<value optimized out>,
msg=0x78fe98) at action.c:139
#16 0x00000000004114d3 in do_action (a=0x77f028, msg=0x78fe98) at
action.c:705
#17 0x000000000040e7e5 in run_action_list (a=<value optimized out>,
msg=0x78fe98) at action.c:139
#18 0x00000000004125fe in run_top_route (a=0x777e78, msg=0x78fe98) at
action.c:119
#19 0x000000000045e898 in receive_msg (
    buf=0x749180 "REGISTER sip:x.x.x.x SIP/2.0\r\nCSeq: 58
REGISTER\r\nVia: SIP/2.0/UDP
x.x.x.x:5068;branch=z9hG4bK5ca4685b-befc-dd11-911f-0015c5404858;rport\r\nUser-Agent:
Ekiga/2.0.12\r\nAuthorization: Dig"..., len=750, rcv_info=0x7fff22578090)
at receive.c:165
#20 0x000000000049d3a6 in udp_rcv_loop () at udp_server.c:449
#21 0x00000000004291fb in main (argc=<value optimized out>,
argv=0x7fff22578278) at main.c:778


----------------------------------------------------------------------

Comment By: Bogdan-Andrei Iancu (bogdan_iancu)
Date: 2009-02-18 23:02

Message:
Hi Om,

I hopefully fixed the problem - please update from SVN and give it another
try. Let me know if now works.

Thanks and regards,
Bogdan

----------------------------------------------------------------------

Comment By: Om Bikram Thapa (omthapa)
Date: 2009-02-18 15:11

Message:
I modified domain in opensips domain table, immediately after that the
server crashed upon registration event with log  general protection
ip:7f249016986c sp:7fff992bf320 error:0 in
libmysqlclient.so.15.0.0[7f2490110000+1bf000]" and gdb backtrace now points
to different code:

----------
#0  0x00007f7a4c26f86c in mysql_stmt_fetch () from
/usr/lib/libmysqlclient.so.15
#1  0x00007f7a4c628a48 in db_mysql_convert_result (_h=0x78b278,
_r=0x78ba28) at res.c:161
#2  0x00007f7a4c626aaa in db_mysql_store_result (_h=0x78b278,
_r=0x7fff553c5770) at dbase.c:513
#3  0x00007f7a4c626e39 in db_mysql_query (_h=0x78b278, _k=<value optimized
out>, _op=<value optimized out>, _v=0x7fff553c56d0, _c=<value optimized
out>,
    _n=1, _nc=2, _o=0x0, _r=0x7fff553c5770) at dbase.c:593
#4  0x00007f7a48da4398 in authorize (_m=0x78fe98, _realm=<value optimized
out>, _table=<value optimized out>, _hftype=<value optimized out>)
    at authorize.c:107
#5  0x000000000040f869 in do_action (a=0x780a48, msg=0x78fe98) at
action.c:961
#6  0x000000000040e7e5 in run_action_list (a=<value optimized out>,
msg=0x78fe98) at action.c:139
#7  0x000000000046f194 in eval_elem (e=0x780b18, msg=0x78fe98, val=0x20)
at route.c:1189
#8  0x00000000004708ed in eval_expr (e=0xe543d0, msg=0x78fe98, val=0x0) at
route.c:1486
#9  0x000000000047089c in eval_expr (e=0x780b60, msg=0x78fe98, val=0x0) at
route.c:1502
#10 0x00000000004708c5 in eval_expr (e=0x780ba8, msg=0x78fe98, val=0x0) at
route.c:1507
#11 0x000000000040f91c in do_action (a=0x780f40, msg=0x78fe98) at
action.c:688
#12 0x000000000040e7e5 in run_action_list (a=<value optimized out>,
msg=0x78fe98) at action.c:139
#13 0x00000000004114d3 in do_action (a=0x781eb0, msg=0x78fe98) at
action.c:705
#14 0x000000000040e7e5 in run_action_list (a=<value optimized out>,
msg=0x78fe98) at action.c:139
#15 0x0000000000410e07 in do_action (a=0x77ee88, msg=0x78fe98) at
action.c:119
#16 0x000000000040e7e5 in run_action_list (a=<value optimized out>,
msg=0x78fe98) at action.c:139
#17 0x00000000004114d3 in do_action (a=0x77f028, msg=0x78fe98) at
action.c:705
#18 0x000000000040e7e5 in run_action_list (a=<value optimized out>,
msg=0x78fe98) at action.c:139
#19 0x00000000004125fe in run_top_route (a=0x777e78, msg=0x78fe98) at
action.c:119
#20 0x000000000045e898 in receive_msg (
    buf=0x749180 "REGISTER sip:x.x.x.x;transport=UDP SIP/2.0\r\nVia:
SIP/2.0/UDP
x.x.x.x:5060;branch=z9hG4bKgcjsr9edklicvlhif2tfvub;rport\r\nFrom:
<sip:300000 at x.x."..., len=693, rcv_info=0x7fff553c6ee0) at receive.c:165
#21 0x000000000049d3a6 in udp_rcv_loop () at udp_server.c:449
#22 0x00000000004291fb in main (argc=<value optimized out>,
argv=0x7fff553c70c8) at main.c:778
-----------------

I think this crash is also related to the same issue.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=2608188&group_id=232389


From noreply at sourceforge.net  Fri Feb 27 22:41:23 2009
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 27 Feb 2009 21:41:23 +0000
Subject: [OpenSIPS-Devel] [ opensips-Bugs-2557032 ] Bug: opensipsctl script
	with Postgres
Message-ID: <E1LdASR-0003DX-J3@1bkjzd1.ch3.sourceforge.com>

Bugs item #2557032, was opened at 2009-02-02 15: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=2557032&group_id=232389

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: tools
Group: 1.4.x
Status: Open
>Resolution: Accepted
Priority: 5
Private: No
Submitted By: David Roberge (xittel)
>Assigned to: Bogdan-Andrei Iancu (bogdan_iancu)
Summary: Bug: opensipsctl script with Postgres

Initial Comment:
Hi, 
 
I am using OpenSIPS 1.4.4 with Postgres 8.3 and I am running into two problems with the opensipsctl script. 
 
1. It seems that Postgres does not support the CONCAT SQL function. I had to remove all CONCAT function calls from the script and replace them with || operators in order to use the script properly. 
 
2. I also encountered a problem when adding subscribers via the opensipsctl script. Before adding new subscriber, the script checks that no alias with the same name as the new subscriber exists in the DB. However, the script seems to be written with MySql in mind. The check_db_alias() function does not process the output of psql properly and thinks that an alias already exists. 
 
The script thinks that the last line of the output of psql contains the number of returned records. It thus set the $CNT variable to the value of the last line of the output. However, the last line is a blank line. Since the $CNT variable is set to blank, it is therefore != 0. The $ALIAS_DB_EXISTS variable is set to 1 and the script thinks that an alias exists even thought it does not. This prevents the addition of new subscribers into the DB. 
 
 
See below for the function code. 
 
---------------------------------------------- 
check_db_alias() { 
require_dbengine 
 
ALIAS_DB_EXISTS=0 
 
QUERY="select count(*) from $DA_TABLE where $DA_ALIAS_USER_COLUMN='$1' \ 
and $DA_ALIAS_DOMAIN_COLUMN='$2';" 
CNT=`$DBROCMD "$QUERY" | $EGREP -v ERROR | $LAST_LINE` 
mdbg "check_db_alias: alias counter=$CNT" 
if [ "$CNT" = "0" ] ; then 
ALIAS_DB_EXISTS=0 
else 
#ALIAS_DB_EXISTS=1 
ALIAS_DB_EXISTS=0 
fi 
} 
---------------------------------------------- 
 
 
and the actual output of the PSQL query: 
 
---------------------------------------------- 
count 
------- 
0 
(1 row) 
 
---------------------------------------------- 
 
I patched the script to force the $ALIAS_DB_EXISTS to 0 but the alias check is no more performed. 
 
Thanks. 
 
David


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=2557032&group_id=232389


From noreply at sourceforge.net  Fri Feb 27 22:49:09 2009
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 27 Feb 2009 21:49:09 +0000
Subject: [OpenSIPS-Devel] [ opensips-Bugs-2646700 ] [uac] uac_replace_from()
	and TM callbacks
Message-ID: <E1LdAZx-0003kM-1L@1bkjzd1.ch3.sourceforge.com>

Bugs item #2646700, was opened at 2009-02-27 23:49
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=2646700&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: Bogdan-Andrei Iancu (bogdan_iancu)
Assigned to: Bogdan-Andrei Iancu (bogdan_iancu)
Summary: [uac] uac_replace_from() and TM callbacks

Initial Comment:
there are several issues here:

1) protect against calling this function more than once per branch

2) avoid multiple registration on TM callbacks when using the function from different branches

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=2646700&group_id=232389


From bogdan at voice-system.ro  Fri Feb 27 23:11:59 2009
From: bogdan at voice-system.ro (Bogdan-Andrei Iancu)
Date: Fri, 27 Feb 2009 22:11:59 +0000
Subject: [OpenSIPS-Devel] SF.net SVN: opensips:[5382]
	branches/1.4/packaging/rpm
Message-ID: <E1LdAw3-0000v7-S8@3kljzd1.ch3.sourceforge.com>

Revision: 5382
          http://opensips.svn.sourceforge.net/opensips/?rev=5382&view=rev
Author:   bogdan_iancu
Date:     2009-02-27 22:11:59 +0000 (Fri, 27 Feb 2009)

Log Message:
-----------
replace broken opensips.spec-4.1 with working opensips.spec-4.4.

Closes patch 2641715.
Credits go to Marc LEURENT and Julian Yap

Added Paths:
-----------
    branches/1.4/packaging/rpm/opensips.spec-4.4

Removed Paths:
-------------
    branches/1.4/packaging/rpm/opensips.spec-4.1


This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site.


From noreply at sourceforge.net  Fri Feb 27 23:12:53 2009
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 27 Feb 2009 22:12:53 +0000
Subject: [OpenSIPS-Devel] [ opensips-Patches-2641715 ] Working opensips.spec
	for CentOS RPM
Message-ID: <E1LdAwv-0005de-Rj@d55xhf1.ch3.sourceforge.com>

Patches item #2641715, was opened at 2009-02-26 15:32
Message generated for change (Comment added) made by bogdan_iancu
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086412&aid=2641715&group_id=232389

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: packaging
Group: 1.4.x
>Status: Closed
>Resolution: Accepted
Priority: 5
Private: No
Submitted By: Marc LEURENT (lftsy)
>Assigned to: Bogdan-Andrei Iancu (bogdan_iancu)
Summary: Working opensips.spec for CentOS RPM

Initial Comment:
You'll find attached a patch to replace broken opensips.spec-4.1 with working opensips.spec-4.4.
Here is the changelog:

Thu Feb 26 2009 Julian Yap <julianokyap at gmail.com>
 * Update spec to OpenSIPS version 1.4.4. Rename database module
names. Rename PUA module. Fix dependencies. Minor build fixes.
Additional files and new modules.

----------------------------------------------------------------------

>Comment By: Bogdan-Andrei Iancu (bogdan_iancu)
Date: 2009-02-28 00:12

Message:
Thank you guys - could you the same great job and re-generate the spec for
trunk version ? 

Regards,
Bogdan

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086412&aid=2641715&group_id=232389


From noreply at sourceforge.net  Sat Feb 28 19:22:15 2009
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat, 28 Feb 2009 18:22:15 +0000
Subject: [OpenSIPS-Devel] [ opensips-Bugs-2649267 ] Crash in anchor_lump
Message-ID: <E1LdTpH-0004ZB-Tr@g45xhf1.ch3.sourceforge.com>

Bugs item #2649267, was opened at 2009-02-28 18:22
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=2649267&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: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: Crash in anchor_lump

Initial Comment:
Feb 28 12:00:26 vs-netlp-196 opensips[2805]: CRITICAL:core:anchor_lump: offset exceeds message size (952 > 949) aborting...
Feb 28 12:00:26 vs-netlp-196 opensips[2768]: INFO:core:handle_sigs: child process 2805 exited by a signal 6
Feb 28 12:00:26 vs-netlp-196 opensips[2851]: CRITICAL:core:receive_fd: EOF on 12
Feb 28 12:00:26 vs-netlp-196 opensips[2768]: INFO:core:handle_sigs: core was generated
Feb 28 12:00:26 vs-netlp-196 opensips[2768]: INFO:core:handle_sigs: terminating due to SIGCHLD
Feb 28 12:00:26 vs-netlp-196 opensips[2851]: INFO:core:sig_usr: signal 15 received
Feb 28 12:00:26 vs-netlp-196 opensips[2837]: INFO:core:sig_usr: signal 15 received
Feb 28 12:00:26 vs-netlp-196 opensips[2843]: INFO:core:sig_usr: signal 15 received


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=2649267&group_id=232389


From noreply at sourceforge.net  Sat Feb 28 19:25:06 2009
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat, 28 Feb 2009 18:25:06 +0000
Subject: [OpenSIPS-Devel] [ opensips-Bugs-2649267 ] Crash in anchor_lump
Message-ID: <E1LdTs2-0006zb-6a@b55xhf1.ch3.sourceforge.com>

Bugs item #2649267, was opened at 2009-02-28 18:22
Message generated for change (Comment added) made by nobody
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=2649267&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: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: Crash in anchor_lump

Initial Comment:
Feb 28 12:00:26 vs-netlp-196 opensips[2805]: CRITICAL:core:anchor_lump: offset exceeds message size (952 > 949) aborting...
Feb 28 12:00:26 vs-netlp-196 opensips[2768]: INFO:core:handle_sigs: child process 2805 exited by a signal 6
Feb 28 12:00:26 vs-netlp-196 opensips[2851]: CRITICAL:core:receive_fd: EOF on 12
Feb 28 12:00:26 vs-netlp-196 opensips[2768]: INFO:core:handle_sigs: core was generated
Feb 28 12:00:26 vs-netlp-196 opensips[2768]: INFO:core:handle_sigs: terminating due to SIGCHLD
Feb 28 12:00:26 vs-netlp-196 opensips[2851]: INFO:core:sig_usr: signal 15 received
Feb 28 12:00:26 vs-netlp-196 opensips[2837]: INFO:core:sig_usr: signal 15 received
Feb 28 12:00:26 vs-netlp-196 opensips[2843]: INFO:core:sig_usr: signal 15 received


----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2009-02-28 18:25

Message:
Core was generated by `/usr/local/sbin/opensips -P /var/run/opensips.pid'.
Program terminated with signal 6, Aborted.
#0  0x00fe9402 in __kernel_vsyscall ()
(gdb) bt
#0  0x00fe9402 in __kernel_vsyscall ()
#1  0x003f7f30 in raise () from /lib/i686/nosegneg/libc.so.6
#2  0x003f9911 in abort () from /lib/i686/nosegneg/libc.so.6
#3  0x0805ffcf in anchor_lump (msg=0x81b2770, offset=950, len=0,
type=HDR_OTHER_T) at data_lump.c:345
#4  0x0021d382 in force_rtp_proxy2_f (msg=0x81b2770, str1=0xbfdf3dbb "",
str2=0xbfdf3d8c "200.69.XXX.197") at nathelper.c:2745
#5  0x00220332 in force_rtp_proxy0_f (msg=0x81b2770, str1=0x0, str2=0x0)
at nathelper.c:2772
#6  0x08052fa6 in do_action (a=0x81ab8a8, msg=0x81b2770) at action.c:845
#7  0x08055819 in run_action_list (a=0x81ab8a8, msg=0x81b2770) at
action.c:138
#8  0x080544c5 in do_action (a=0x81ab910, msg=0x81b2770) at action.c:717
#9  0x08055819 in run_action_list (a=0x81ab910, msg=0x81b2770) at
action.c:138
#10 0x08054df2 in do_action (a=0x81ab978, msg=0x81b2770) at action.c:723
#11 0x08055819 in run_action_list (a=0x81ab978, msg=0x81b2770) at
action.c:138
#12 0x08054088 in do_action (a=0x81ab338, msg=0x81b2770) at action.c:118
#13 0x08055819 in run_action_list (a=0x81a4068, msg=0x81b2770) at
action.c:138
#14 0x08055bb3 in run_top_route (a=0x81a4068, msg=0x81b2770) at
action.c:118
#15 0x08094f79 in receive_msg (
    buf=0x817a200 "INVITE sip:002914530254 at voip.XXXXXXXX.com.ar
SIP/2.0\r\nVia: SIP/2.0/UDP
200.59.112.179:33131;branch=z9hG4bK-d87543-fd18d04ea12c3a1d-1--d87543-;rport\r\nMax-Forwards:
69\r\nContact: <sip:1191 at 200.59.112.179"..., len=947, rcv_info=0xbfdf4964)
at receive.c:165
#16 0x080d7b37 in udp_rcv_loop () at udp_server.c:449
#17 0x0806d5ce in main (argc=3, argv=0xbfdf4b54) at main.c:780


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=2649267&group_id=232389


From noreply at sourceforge.net  Sat Feb 28 19:26:49 2009
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat, 28 Feb 2009 18:26:49 +0000
Subject: [OpenSIPS-Devel] [ opensips-Bugs-2649267 ] Crash in anchor_lump
Message-ID: <E1LdTth-0000un-4d@3bkjzd1.ch3.sourceforge.com>

Bugs item #2649267, was opened at 2009-02-28 18:22
Message generated for change (Comment added) made by nobody
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=2649267&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: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: Crash in anchor_lump

Initial Comment:
Feb 28 12:00:26 vs-netlp-196 opensips[2805]: CRITICAL:core:anchor_lump: offset exceeds message size (952 > 949) aborting...
Feb 28 12:00:26 vs-netlp-196 opensips[2768]: INFO:core:handle_sigs: child process 2805 exited by a signal 6
Feb 28 12:00:26 vs-netlp-196 opensips[2851]: CRITICAL:core:receive_fd: EOF on 12
Feb 28 12:00:26 vs-netlp-196 opensips[2768]: INFO:core:handle_sigs: core was generated
Feb 28 12:00:26 vs-netlp-196 opensips[2768]: INFO:core:handle_sigs: terminating due to SIGCHLD
Feb 28 12:00:26 vs-netlp-196 opensips[2851]: INFO:core:sig_usr: signal 15 received
Feb 28 12:00:26 vs-netlp-196 opensips[2837]: INFO:core:sig_usr: signal 15 received
Feb 28 12:00:26 vs-netlp-196 opensips[2843]: INFO:core:sig_usr: signal 15 received


----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2009-02-28 18:26

Message:
(gdb) bt full
#0  0x00fe9402 in __kernel_vsyscall ()
No symbol table info available.
#1  0x003f7f30 in raise () from /lib/i686/nosegneg/libc.so.6
No symbol table info available.
#2  0x003f9911 in abort () from /lib/i686/nosegneg/libc.so.6
No symbol table info available.
#3  0x0805ffcf in anchor_lump (msg=0x81b2770, offset=950, len=0,
type=HDR_OTHER_T) at data_lump.c:345
        tmp = <value optimized out>
        prev = <value optimized out>
        t = <value optimized out>
        list = <value optimized out>
        __FUNCTION__ = "anchor_lump"
#4  0x0021d382 in force_rtp_proxy2_f (msg=0x81b2770, str1=0xbfdf3dbb "",
str2=0xbfdf3d8c "200.69.XXX.197") at nathelper.c:2745
        body = {
  s = 0x817a44d "v=0\r\no=- 5490616 5490639 IN IP4
200.59.112.179\r\ns=eyeBeam\r\nc=IN IP4 200.59.112.179\r\nt=0 0\r\nm=audio
35867 RTP/AVP 100 6 0 8 3 18 98 97 5 102 101\r\na=alt:1 1 : 1EDD7A3B
DE47B706 200.59.112.179 35867\r\na=f"..., len = 361}
        body1 = {
  s = 0x817a488 "c=IN IP4 200.59.112.179\r\nt=0 0\r\nm=audio 35867 RTP/AVP
100 6 0 8 3 18 98 97 5 102 101\r\na=alt:1 1 : 1EDD7A3B DE47B706
200.59.112.179 35867\r\na=fmtp:101 0-15\r\na=rtpmap:100
speex/16000\r\na=rtpmap:98 ilbc/80"..., len = 302}
        oldport = {
  s = 0x817a4b0 "35867 RTP/AVP 100 6 0 8 3 18 98 97 5 102 101\r\na=alt:1 1
: 1EDD7A3B DE47B706 200.59.112.179 35867\r\na=fmtp:101 0-15\r\na=rtpmap:100
speex/16000\r\na=rtpmap:98 ilbc/8000\r\na=rtpmap:97
speex/8000\r\na=rtpmap:102"..., len = 5}
        oldip = {
  s = 0x817a491 "200.59.112.179\r\nt=0 0\r\nm=audio 35867 RTP/AVP 100 6 0
8 3 18 98 97 5 102 101\r\na=alt:1 1 : 1EDD7A3B DE47B706 200.59.112.179
35867\r\na=fmtp:101 0-15\r\na=rtpmap:100 speex/16000\r\na=rtpmap:98
ilbc/8000\r\na=rtp"..., len = 14}
        newport = {s = 0x819ad38 "35456", len = 5}
        newip = {s = 0x2286af "200.69.196.196", len = 14}
        callid = {
  s = 0x817a354 "103ddf45602ebf12 at QVJJRUwx\r\nCSeq: 1 INVITE\r\nAllow:
INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY, MESSAGE, SUBSCRIBE,
INFO\r\nContent-Type: application/sdp\r\nSupported:
eventlist\r\nUser-Agent: eyeBeam r"..., len = 25}
        create = 1
        len = <value optimized out>
        asymmetric = 0
        flookup = 0
        argc = 2
        proxied = 0
        real = 0
        orgip = 0
        commip = 0
        oidx = 1
        pf = 2
        pf1 = 2
        force = 0
        swap = 0
        opts = "U\000\000\000?\017Q\000??\027\b\000\000\000"
        cp = 0x2286be ""
        cpend = <value optimized out>
        next = <value optimized out>
        ap = <value optimized out>
        argv = {0x2286a9 "35456", 0x2286af "200.69.196.196", 0x0, 0x0,
0x0, 0x0, 0x0, 0x0, 0x0, 0x0}
        anchor = <value optimized out>
        node = <value optimized out>
        v = {{iov_base = 0x2287c0, iov_len = 9}, {iov_base = 0xbfdf3cd8,
iov_len = 1}, {iov_base = 0x225a49, iov_len = 1}, {iov_base = 0x817a354,
    iov_len = 25}, {iov_base = 0x225a49, iov_len = 1}, {iov_base =
0x228c00, iov_len = 14}, {iov_base = 0x225a49, iov_len = 1}, {iov_base =
0x817a4b0,
    iov_len = 5}, {iov_base = 0x225a49, iov_len = 1}, {iov_base =
0x817a341, iov_len = 8}, {iov_base = 0x225b48, iov_len = 1}, {iov_base =
0xbfdf3cc4,
    iov_len = 1}, {iov_base = 0x225a49, iov_len = 1}, {iov_base = 0x0,
iov_len = 0}, {iov_base = 0x225b48, iov_len = 1}, {iov_base = 0xbfdf3cc4,
    iov_len = 1}}
        v1p = <value optimized out>
        v2p = 0x817a44d "v=0\r\no=- 5490616 5490639 IN IP4
200.59.112.179\r\ns=eyeBeam\r\nc=IN IP4 200.59.112.179\r\nt=0 0\r\nm=audio
35867 RTP/AVP 100 6 0 8 3 18 98 97 5 102 101\r\na=alt:1 1 : 1EDD7A3B
DE47B706 200.59.112.179 35867\r\na=f"...
        c1p = 0x817a488 "c=IN IP4 200.59.112.179\r\nt=0 0\r\nm=audio 35867
RTP/AVP 100 6 0 8 3 18 98 97 5 102 101\r\na=alt:1 1 : 1EDD7A3B DE47B706
200.59.112.179 35867\r\na=fmtp:101 0-15\r\na=rtpmap:100
speex/16000\r\na=rtpmap:98 ilbc/80"...
        c2p = 0x0
        m1p = <value optimized out>
        m2p = 0x817a4a8 "m=audio 35867 RTP/AVP 100 6 0 8 3 18 98 97 5 102
101\r\na=alt:1 1 : 1EDD7A3B DE47B706 200.59.112.179 35867\r\na=fmtp:101
0-15\r\na=rtpmap:100 speex/16000\r\na=rtpmap:98 ilbc/8000\r\na=rtpmap:97
speex/8000\r\na=rt"...
        bodylimit = 0x817a5b6 "2\r\nVia: SIP/2.0/UDP
200.73.183.203;rport=5060;received=200.73.183.203;branch=0\r\nVia:
SIP/2.0/UDP 
200.73.182.228:5060;rport=56505;x-route-tag=\"tgrp:SKYTONE-BASICO\";branch=z9hG4bK225472653\r\nFrom:
\"anon"...
        o1p = 0x0
        medianum_buf =
"1\000??\000\000\000\000quG\000\212?@\000\000\000\000"
        medianum = 1
        tmpstr1 = {
  s = 0x817a4a8 "m=audio 35867 RTP/AVP 100 6 0 8 3 18 98 97 5 102
101\r\na=alt:1 1 : 1EDD7A3B DE47B706 200.59.112.179 35867\r\na=fmtp:101
0-15\r\na=rtpmap:100 speex/16000\r\na=rtpmap:98 ilbc/8000\r\na=rtpmap:97
speex/8000\r\na=rt"..., len = 270}
        c1p_altered = 1
        __FUNCTION__ = "force_rtp_proxy2_f"
#5  0x00220332 in force_rtp_proxy0_f (msg=0x81b2770, str1=0x0, str2=0x0)
at nathelper.c:2772
        arg = ""
#6  0x08052fa6 in do_action (a=0x81ab8a8, msg=0x81b2770) at action.c:845
        ret = <value optimized out>
        v = <value optimized out>
        to = <value optimized out>
        p = <value optimized out>
        tmp = <value optimized out>
        end = <value optimized out>
        crt = <value optimized out>
        len = <value optimized out>
        user = <value optimized out>
        uri = {user = {s = 0x81ab7d0 "\002", len = 135997296}, passwd = {s
= 0x0, len = 4439232}, host = {s = 0x512140 "", len = 161736688}, port = {
    s = 0x0, len = 0}, params = {s = 0x46c914 "\201??F\n", len =
161736680}, headers = {s = 0xbfdf413c "\a?\027\b???\t", len = 0},
port_no = 0, proto = 0,
  type = 5312500, transport = {s = 0x0, len = 1}, ttl = {s = 0xbfdf4200
"(B??\2147H", len = 4722294}, user_param = {s = 0x9a3e7f0 "\200!Q", len =
17},
  maddr = {s = 0x88 <Address 0x88 out of bounds>, len = -322277503},
method = {s = 0x81b3088 "??\027\b", len = 4194304}, lr = {
    s = 0x1 <Address 0x1 out of bounds>, len = 135766535}, r2 = {s = 0x25
<Address 0x25 out of bounds>, len = 2141312}, transport_val = {
    s = 0xc <Address 0xc out of bounds>, len = 4732812}, ttl_val = {s =
0x0, len = 135966032}, user_param_val = {s = 0x81b2770 "?\b", len = 0},
maddr_val = {
    s = 0xbfdf4268 "", len = 134557606}, method_val = {s = 0x81b2770
"?\b", len = -1240879032}, lr_val = {s = 0x0, len = 0}, r2_val = {s = 0x0,
len = 0}}
        next_hop = {user = {s = 0x0, len = 0}, passwd = {s = 0x0, len =
0}, host = {s = 0x0, len = 0}, port = {s = 0x0, len = 0}, params = {s =
0x0,
    len = 0}, headers = {s = 0x0, len = 0}, port_no = 0, proto = 0, type =
ERROR_URI_T, transport = {s = 0x0, len = 0}, ttl = {s = 0x0, len = 0},
  user_param = {s = 0x0, len = -1552065627}, maddr = {s = 0x0, len =
1655571}, method = {s = 0x0, len = 0}, lr = {s = 0x194a13 "\201???",
    len = -1552065627}, r2 = {s = 0x200 <Address 0x200 out of bounds>, len
= 2141324}, transport_val = {s = 0x20ac88 "0254", len = 2140016}, ttl_val =
{
    s = 0xb609b048 "\030?\t?", len = -1240879032}, user_param_val = {s =
0xbfdf3ff8 "hB???/\005\bp'\033\bH?\t?", len = 2098015}, maddr_val = {
    s = 0xb609b048 "\030?\t?", len = -1075888164}, method_val = {s =
0xbfdf3fe8 "", len = 135968760}, lr_val = {s = 0x81b2770 "?\b", len = 4},
r2_val = {
    s = 0xbfdf4078 "?B???D\005\b??\032\bp'\033\b", len =
134889973}}
        u = <value optimized out>
        port = <value optimized out>
        cmatch = <value optimized out>
        aitem = <value optimized out>
        adefault = <value optimized out>
        spec = <value optimized out>
        model = <value optimized out>
        val = {rs = {s = 0x0, len = 0}, ri = 0, flags = 1}
        __FUNCTION__ = "do_action"
#7  0x08055819 in run_action_list (a=0x81ab8a8, msg=0x81b2770) at
action.c:138
        ret = 135969040
        t = (struct action *) 0x81ab8a8
        __FUNCTION__ = "run_action_list"


----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2009-02-28 18:25

Message:
Core was generated by `/usr/local/sbin/opensips -P /var/run/opensips.pid'.
Program terminated with signal 6, Aborted.
#0  0x00fe9402 in __kernel_vsyscall ()
(gdb) bt
#0  0x00fe9402 in __kernel_vsyscall ()
#1  0x003f7f30 in raise () from /lib/i686/nosegneg/libc.so.6
#2  0x003f9911 in abort () from /lib/i686/nosegneg/libc.so.6
#3  0x0805ffcf in anchor_lump (msg=0x81b2770, offset=950, len=0,
type=HDR_OTHER_T) at data_lump.c:345
#4  0x0021d382 in force_rtp_proxy2_f (msg=0x81b2770, str1=0xbfdf3dbb "",
str2=0xbfdf3d8c "200.69.XXX.197") at nathelper.c:2745
#5  0x00220332 in force_rtp_proxy0_f (msg=0x81b2770, str1=0x0, str2=0x0)
at nathelper.c:2772
#6  0x08052fa6 in do_action (a=0x81ab8a8, msg=0x81b2770) at action.c:845
#7  0x08055819 in run_action_list (a=0x81ab8a8, msg=0x81b2770) at
action.c:138
#8  0x080544c5 in do_action (a=0x81ab910, msg=0x81b2770) at action.c:717
#9  0x08055819 in run_action_list (a=0x81ab910, msg=0x81b2770) at
action.c:138
#10 0x08054df2 in do_action (a=0x81ab978, msg=0x81b2770) at action.c:723
#11 0x08055819 in run_action_list (a=0x81ab978, msg=0x81b2770) at
action.c:138
#12 0x08054088 in do_action (a=0x81ab338, msg=0x81b2770) at action.c:118
#13 0x08055819 in run_action_list (a=0x81a4068, msg=0x81b2770) at
action.c:138
#14 0x08055bb3 in run_top_route (a=0x81a4068, msg=0x81b2770) at
action.c:118
#15 0x08094f79 in receive_msg (
    buf=0x817a200 "INVITE sip:002914530254 at voip.XXXXXXXX.com.ar
SIP/2.0\r\nVia: SIP/2.0/UDP
200.59.112.179:33131;branch=z9hG4bK-d87543-fd18d04ea12c3a1d-1--d87543-;rport\r\nMax-Forwards:
69\r\nContact: <sip:1191 at 200.59.112.179"..., len=947, rcv_info=0xbfdf4964)
at receive.c:165
#16 0x080d7b37 in udp_rcv_loop () at udp_server.c:449
#17 0x0806d5ce in main (argc=3, argv=0xbfdf4b54) at main.c:780


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=2649267&group_id=232389


