i have now managed to get all my stuff working using sr except
t_uac_dlg. t_uac_dlg is not working because for some reason sr tm
module does not implement t_uac_dlg and mi_rpc tells "async mi cmd not
implemented yet".
i would prefer native support of t_uac_dlg in tm module, because the
idea was that sr will use ser tm module. if t_uac is difficult to
implement in ser tm module or if that would still not make t_uac_dlg to
work via rpc, then i guess i need to wait until mi_rpc supports async mi
functions.
otherwise things thus look pretty good to me. thanks for your efforts.
-- juha
i tried dlg_bridge, but found some problems. first, if i didn't define
tm module param fr_inv_timer_avp, i got these kind of errors to syslog:
Jul 22 10:28:53 localhost /usr/sbin/sip-router[15075]: INFO: INVITE <sip:jh@test.fi> by untrusted <sip:controller@kamailio.org> from <192.98.101.10>
Jul 22 10:28:53 localhost /usr/sbin/sip-router[15073]: INFO: <core> [tcp_main.c:1919]: tcp_send: quick connect for 0xb3331098
Jul 22 10:28:53 localhost /usr/sbin/sip-router[15075]: ERROR: <core> [usr_avp.c:159]: ERROR:avp:add_avp: 0 ID or NULL NAME AVP!
Jul 22 10:28:53 localhost /usr/sbin/sip-router[15075]: ERROR: tm [t_serial.c:430]: setting of fr_inv_timer_avp failed
Jul 22 10:28:53 localhost /usr/sbin/sip-router[15075]: ERROR: Cannot get contacts for INVITE <sip:jh_test_fi@192.98.101.10:5074;transport=udp>!
nowhere in dialog module docs is mentioned that tm fr_inv_timer_avp
would need to be defined. is defining fr_inv_timer_avp mandatory in
order to make dlg_bridge to work?
after i defined this avp, and give command
mi dlg_bridge sip:jh@test.fi sip:test@test.fi sip:192.98.101.10:5060
sip:jh@test.fi rings, but when twinkle answers, it does not receive a
refer.
when sip:jh@test.fi then ends the call, by sending bye, i noticed that
bye goes to sip:kamailio.org:5060 (contact uri in invite) although i
have defined
modparam("dialog", "bridge_controller", "sip:click2dial@192.98.101.10:5060")
finally, if these issues get solved, is it even in theory possible to
add an "extra headers" parameter to dlg_bridge mi command?
-- juha
Revision: 5905
http://openser.svn.sourceforge.net/openser/?rev=5905&view=rev
Author: miconda
Date: 2009-07-21 20:55:14 +0000 (Tue, 21 Jul 2009)
Log Message:
-----------
- applied patch from #2824350
- sorts out DB update for subscriptions based on fallback2db parameter
- credits to Alex Hermann
Modified Paths:
--------------
branches/1.5/modules/presence/README
branches/1.5/modules/presence/doc/presence_admin.xml
branches/1.5/modules/presence/hash.c
branches/1.5/modules/presence/hash.h
branches/1.5/modules/presence/subscribe.c
branches/1.5/modules/rls/rls.c
branches/1.5/modules/rls/subscribe.c
This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site.
Bugs item #2824350, was opened at 2009-07-20 17:49
Message generated for change (Comment added) made by klaus_darilion
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=743020&aid=2824350&group_…
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: modules
Group: ver 1.5.x
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Alex Hermann (axlh)
Assigned to: Nobody/Anonymous (nobody)
Summary: Presence DB support completely broken
Initial Comment:
As subject.
commit 5840 did the damage
----------------------------------------------------------------------
>Comment By: Klaus Darilion (klaus_darilion)
Date: 2009-07-21 15:43
Message:
What about having a new parameter like userloc?
db_mode=
=0: no DB
=1: read from cache, write/update to cache and DB
=2: read from cache, write to cache and delayed write/update to DB
=3: db_only, no cache
----------------------------------------------------------------------
Comment By: Nobody/Anonymous (nobody)
Date: 2009-07-21 14:00
Message:
Patch is ok, cleaner with new parameter rather than playing with falback2db
value. I will apply it.
Updating on timer is good for the cases of sudden crash, maybe a new mode
to skip timer updates and store only at shutdown is more appropriate.
----------------------------------------------------------------------
Comment By: Alex Hermann (axlh)
Date: 2009-07-21 13:11
Message:
I decided to dive into the code some more. It's a bit messy. There are 2
modes of operation determined by fallback2db. Both modes don't work
correctly, the documentation for the modes contradict the code it
contradicts ITSELF. So the first thing to do to fix this is to get the
desired behavior for both modes documented.
>From the code I deduced the following behavior:
fallback mode:
init: load from database, keep data in tables
runtime: insert/update records in table on timer event
shutdown: flush cache to db
non-fallback mode:
init: load from database, empty table
runtime: no inserts but try to update table (won't work because table is
emptied)
shutdown: flush cache to db (fails, because all entries are marked
NO_UPDATEDB_FLAG du to the (failed) updates at runtime). Result is an empty
table after shutdown.
The documentation says in fallback mode the cache isn't used. This is
impossible in the current code. Later in the docs it is said only on cache
misses, the db is used. This seems reasonable behavior.
The main question is: should the db be updated during runtime or only on
shutdown when in non-fallback mode?
Attached patch creates the following behavior:
for both modes:
init: load from database, keep table contents
runtime: update/insert into table on timer event
shutdown: update/insert final time
The only difference in the modes is on lookup (as documentation says) and
is untouched by this patch.
The non-fallback mode should be optimized by not updating the table if the
answer to the above question says so, but that is not as trivial as this
patch.
ps. I found some nice descriptive function names: update_db_subs() and
update_subs_db()....
----------------------------------------------------------------------
Comment By: Nobody/Anonymous (nobody)
Date: 2009-07-20 19:52
Message:
fallback to db is in presence and the insert function is used by rls module
as well. I had no time to check the impact now.
With this idea, to be safe, fallback2db param has to be directed to
another variable, fallback2db initialized to 0 and set to param value in
each child, via child_init. Otherwise can be a conflict of loading order.
----------------------------------------------------------------------
Comment By: Nobody/Anonymous (nobody)
Date: 2009-07-20 18:37
Message:
I don't know if changing the API and ABI is appropriate for the stable
series.
What about setting the fallback2db variable only AFTER loading the DB
contents?
----------------------------------------------------------------------
Comment By: Nobody/Anonymous (nobody)
Date: 2009-07-20 18:22
Message:
The function is used in presence and rls modules. Does not look like big
changes to add a new param to specify the mode. Do you think of something
else?
----------------------------------------------------------------------
Comment By: Alex Hermann (axlh)
Date: 2009-07-20 18:07
Message:
New subscriptions don't get stored in the DB because the test for
'fallback2db' was wrong.
I just noticed the insert_shtable() function is also used to load from DB
initially, so my patch is wrong. Fix is a bit more non-trivial.
The problem is that the function is used for both DB-load at startup and
new subscriptions during runtime. The db_flag in the hash table record
needs to be INSERTDB_FLAG during runtime, and NO_UPDATEDB_FLAG for initial
load.
----------------------------------------------------------------------
Comment By: Nobody/Anonymous (nobody)
Date: 2009-07-20 17:53
Message:
Please provide a bit more details of what got broken.
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=743020&aid=2824350&group_…
Module: sip-router
Branch: master
Commit: 4bc6bf9e8469ffc67dc1e19f1695125180b40f9d
URL: http://git.sip-router.org/cgi-bin/gitweb.cgi/sip-router/?a=commit;h=4bc6bf9…
Author: Andrei Pelinescu-Onciul <andrei(a)iptel.org>
Committer: Andrei Pelinescu-Onciul <andrei(a)iptel.org>
Date: Tue Jul 21 14:53:26 2009 +0200
Merge commit 'origin/tmp/build_local'
* commit 'origin/tmp/build_local':
core: init via_len to cope with no via update flag
tm: local req. route: do not save/restore the avps
tm: local req. route: cache route id
tm: local req. route: always free the tmp sip msg
tm: local req. route rcv init fix
tm: updated execution of event route
core: build_req_buf_from_sip_req() has a new parameter
tm: update to new signature of build_req_buf_from_sip_req()
tm: execute event_route[tm:local-request] if defined
---
Bugs item #2824350, was opened at 2009-07-20 15:49
Message generated for change (Comment added) made by nobody
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=743020&aid=2824350&group_…
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: modules
Group: ver 1.5.x
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Alex Hermann (axlh)
Assigned to: Nobody/Anonymous (nobody)
Summary: Presence DB support completely broken
Initial Comment:
As subject.
commit 5840 did the damage
----------------------------------------------------------------------
Comment By: Nobody/Anonymous (nobody)
Date: 2009-07-21 12:00
Message:
Patch is ok, cleaner with new parameter rather than playing with falback2db
value. I will apply it.
Updating on timer is good for the cases of sudden crash, maybe a new mode
to skip timer updates and store only at shutdown is more appropriate.
----------------------------------------------------------------------
Comment By: Alex Hermann (axlh)
Date: 2009-07-21 11:11
Message:
I decided to dive into the code some more. It's a bit messy. There are 2
modes of operation determined by fallback2db. Both modes don't work
correctly, the documentation for the modes contradict the code it
contradicts ITSELF. So the first thing to do to fix this is to get the
desired behavior for both modes documented.
>From the code I deduced the following behavior:
fallback mode:
init: load from database, keep data in tables
runtime: insert/update records in table on timer event
shutdown: flush cache to db
non-fallback mode:
init: load from database, empty table
runtime: no inserts but try to update table (won't work because table is
emptied)
shutdown: flush cache to db (fails, because all entries are marked
NO_UPDATEDB_FLAG du to the (failed) updates at runtime). Result is an empty
table after shutdown.
The documentation says in fallback mode the cache isn't used. This is
impossible in the current code. Later in the docs it is said only on cache
misses, the db is used. This seems reasonable behavior.
The main question is: should the db be updated during runtime or only on
shutdown when in non-fallback mode?
Attached patch creates the following behavior:
for both modes:
init: load from database, keep table contents
runtime: update/insert into table on timer event
shutdown: update/insert final time
The only difference in the modes is on lookup (as documentation says) and
is untouched by this patch.
The non-fallback mode should be optimized by not updating the table if the
answer to the above question says so, but that is not as trivial as this
patch.
ps. I found some nice descriptive function names: update_db_subs() and
update_subs_db()....
----------------------------------------------------------------------
Comment By: Nobody/Anonymous (nobody)
Date: 2009-07-20 17:52
Message:
fallback to db is in presence and the insert function is used by rls module
as well. I had no time to check the impact now.
With this idea, to be safe, fallback2db param has to be directed to
another variable, fallback2db initialized to 0 and set to param value in
each child, via child_init. Otherwise can be a conflict of loading order.
----------------------------------------------------------------------
Comment By: Nobody/Anonymous (nobody)
Date: 2009-07-20 16:37
Message:
I don't know if changing the API and ABI is appropriate for the stable
series.
What about setting the fallback2db variable only AFTER loading the DB
contents?
----------------------------------------------------------------------
Comment By: Nobody/Anonymous (nobody)
Date: 2009-07-20 16:22
Message:
The function is used in presence and rls modules. Does not look like big
changes to add a new param to specify the mode. Do you think of something
else?
----------------------------------------------------------------------
Comment By: Alex Hermann (axlh)
Date: 2009-07-20 16:07
Message:
New subscriptions don't get stored in the DB because the test for
'fallback2db' was wrong.
I just noticed the insert_shtable() function is also used to load from DB
initially, so my patch is wrong. Fix is a bit more non-trivial.
The problem is that the function is used for both DB-load at startup and
new subscriptions during runtime. The db_flag in the hash table record
needs to be INSERTDB_FLAG during runtime, and NO_UPDATEDB_FLAG for initial
load.
----------------------------------------------------------------------
Comment By: Nobody/Anonymous (nobody)
Date: 2009-07-20 15:53
Message:
Please provide a bit more details of what got broken.
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=743020&aid=2824350&group_…
Bugs item #2824350, was opened at 2009-07-20 17:49
Message generated for change (Comment added) made by axlh
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=743020&aid=2824350&group_…
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: modules
Group: ver 1.5.x
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Alex Hermann (axlh)
Assigned to: Nobody/Anonymous (nobody)
Summary: Presence DB support completely broken
Initial Comment:
As subject.
commit 5840 did the damage
----------------------------------------------------------------------
>Comment By: Alex Hermann (axlh)
Date: 2009-07-21 13:11
Message:
I decided to dive into the code some more. It's a bit messy. There are 2
modes of operation determined by fallback2db. Both modes don't work
correctly, the documentation for the modes contradict the code it
contradicts ITSELF. So the first thing to do to fix this is to get the
desired behavior for both modes documented.
>From the code I deduced the following behavior:
fallback mode:
init: load from database, keep data in tables
runtime: insert/update records in table on timer event
shutdown: flush cache to db
non-fallback mode:
init: load from database, empty table
runtime: no inserts but try to update table (won't work because table is
emptied)
shutdown: flush cache to db (fails, because all entries are marked
NO_UPDATEDB_FLAG du to the (failed) updates at runtime). Result is an empty
table after shutdown.
The documentation says in fallback mode the cache isn't used. This is
impossible in the current code. Later in the docs it is said only on cache
misses, the db is used. This seems reasonable behavior.
The main question is: should the db be updated during runtime or only on
shutdown when in non-fallback mode?
Attached patch creates the following behavior:
for both modes:
init: load from database, keep table contents
runtime: update/insert into table on timer event
shutdown: update/insert final time
The only difference in the modes is on lookup (as documentation says) and
is untouched by this patch.
The non-fallback mode should be optimized by not updating the table if the
answer to the above question says so, but that is not as trivial as this
patch.
ps. I found some nice descriptive function names: update_db_subs() and
update_subs_db()....
----------------------------------------------------------------------
Comment By: Nobody/Anonymous (nobody)
Date: 2009-07-20 19:52
Message:
fallback to db is in presence and the insert function is used by rls module
as well. I had no time to check the impact now.
With this idea, to be safe, fallback2db param has to be directed to
another variable, fallback2db initialized to 0 and set to param value in
each child, via child_init. Otherwise can be a conflict of loading order.
----------------------------------------------------------------------
Comment By: Nobody/Anonymous (nobody)
Date: 2009-07-20 18:37
Message:
I don't know if changing the API and ABI is appropriate for the stable
series.
What about setting the fallback2db variable only AFTER loading the DB
contents?
----------------------------------------------------------------------
Comment By: Nobody/Anonymous (nobody)
Date: 2009-07-20 18:22
Message:
The function is used in presence and rls modules. Does not look like big
changes to add a new param to specify the mode. Do you think of something
else?
----------------------------------------------------------------------
Comment By: Alex Hermann (axlh)
Date: 2009-07-20 18:07
Message:
New subscriptions don't get stored in the DB because the test for
'fallback2db' was wrong.
I just noticed the insert_shtable() function is also used to load from DB
initially, so my patch is wrong. Fix is a bit more non-trivial.
The problem is that the function is used for both DB-load at startup and
new subscriptions during runtime. The db_flag in the hash table record
needs to be INSERTDB_FLAG during runtime, and NO_UPDATEDB_FLAG for initial
load.
----------------------------------------------------------------------
Comment By: Nobody/Anonymous (nobody)
Date: 2009-07-20 17:53
Message:
Please provide a bit more details of what got broken.
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=743020&aid=2824350&group_…
Module: sip-router
Branch: tmp/build_request
Commit: fa699018d34721c79426fa657a68ca46ed0293b7
URL: http://git.sip-router.org/cgi-bin/gitweb.cgi/sip-router/?a=commit;h=fa69901…
Author: Andrei Pelinescu-Onciul <andrei(a)iptel.org>
Committer: Andrei Pelinescu-Onciul <andrei(a)iptel.org>
Date: Tue Jul 21 12:20:16 2009 +0200
tm: local req. route: do not save/restore the avps
- reset_avps() moved after running the local req. route so at
least there is a chance that some avps could be used (although
it's unclear what non-global avps could have made it so far
so it's probably safer to say that in general no defined avps
should be expected).
- no need to save or restore the avps after running the local req.
route (they are reset anyway).
---
modules/tm/uac.c | 34 ++++++----------------------------
1 files changed, 6 insertions(+), 28 deletions(-)
diff --git a/modules/tm/uac.c b/modules/tm/uac.c
index b1a79fa..9a9e52b 100644
--- a/modules/tm/uac.c
+++ b/modules/tm/uac.c
@@ -210,9 +210,6 @@ static inline int t_uac_prepare(uac_req_t *uac_r,
int buf_len1;
int sflag_bk;
int backup_route_type;
- avp_list_t* backup_user_from, *backup_user_to;
- avp_list_t* backup_domain_from, *backup_domain_to;
- avp_list_t* backup_uri_from, *backup_uri_to;
#endif
ret=-1;
@@ -300,10 +297,6 @@ static inline int t_uac_prepare(uac_req_t *uac_r,
new_cell->rt_t2_timeout=cfg_get(tm, tm_cfg, rt_t2_timeout);
#endif
- /* better reset avp list now - anyhow, it's useless from
- * this point (bogdan) */
- reset_avps();
-
set_kr(REQ_FWDED);
request = &new_cell->uac[0].request;
@@ -349,20 +342,8 @@ static inline int t_uac_prepare(uac_req_t *uac_r,
#ifdef USE_COMP
lreq.rcv.comp=dst.comp;
#endif /* USE_COMP */
- /* backup environment (e.g., AVP lists, ...) */
- backup_uri_from = set_avp_list(AVP_TRACK_FROM | AVP_CLASS_URI,
- &new_cell->uri_avps_from);
- backup_uri_to = set_avp_list(AVP_TRACK_TO | AVP_CLASS_URI,
- &new_cell->uri_avps_to);
- backup_user_from = set_avp_list(AVP_TRACK_FROM | AVP_CLASS_USER,
- &new_cell->user_avps_from);
- backup_user_to = set_avp_list(AVP_TRACK_TO | AVP_CLASS_USER,
- &new_cell->user_avps_to);
- backup_domain_from = set_avp_list(
- AVP_TRACK_FROM | AVP_CLASS_DOMAIN,
- &new_cell->domain_avps_from);
- backup_domain_to = set_avp_list(AVP_TRACK_TO | AVP_CLASS_DOMAIN,
- &new_cell->domain_avps_to);
+ /* AVPs are reset anyway afterwards, so no need to
+ backup/restore them*/
sflag_bk = getsflags();
/* run the route */
@@ -372,13 +353,6 @@ static inline int t_uac_prepare(uac_req_t *uac_r,
set_route_type( backup_route_type );
/* restore original environment */
- set_avp_list(AVP_TRACK_FROM | AVP_CLASS_URI, backup_uri_from);
- set_avp_list(AVP_TRACK_TO | AVP_CLASS_URI, backup_uri_to);
- set_avp_list(AVP_TRACK_FROM | AVP_CLASS_USER, backup_user_from);
- set_avp_list(AVP_TRACK_TO | AVP_CLASS_USER, backup_user_to);
- set_avp_list(AVP_TRACK_FROM | AVP_CLASS_DOMAIN,
- backup_domain_from);
- set_avp_list(AVP_TRACK_TO | AVP_CLASS_DOMAIN, backup_domain_to);
setsflagsval(sflag_bk);
if (unlikely(lreq.new_uri.s))
@@ -414,6 +388,10 @@ static inline int t_uac_prepare(uac_req_t *uac_r,
}
#endif
+ /* better reset avp list now - anyhow, it's useless from
+ * this point (bogdan) */
+ reset_avps();
+
new_cell->method.s = buf;
new_cell->method.len = uac_r->method->len;