Anyone else that tries to compile Kamailio 3.1 on OpenBSD?
I get a lot of errors in various modules. modules_s/nathelper fails to compile. I had to add an include file to modules_s/eval to make it compile. Mysql generates a lot of compile warnings...
Gmake modules compiles all modules_k
"gmake install" starts compilation of modules_s
I still have serious doubts of the build system. On both FreeBSD and OpenBSD I see a lot of new stuff being compiled after "gmake", "gmake modules" - when I run "gmake install".
Do we have any automatic compilation tests on these systems? Are they still supported by the dev team?
/O
Dear Folks,
I am using Kamailio server for our project.
I would like to use Video+Texting features and I would like to *disable
audio* in the Kamailio source code.
Could anyone please tell me if I am able to do that. Should I change some
source file.
Thank you.
Regards
Module: sip-router
Branch: master
Commit: 7faa58b0264cb77c991a21bd3b7e3d660596ad85
URL: http://git.sip-router.org/cgi-bin/gitweb.cgi/sip-router/?a=commit;h=7faa58b…
Author: Andrei Pelinescu-Onciul <andrei(a)iptel.org>
Committer: Andrei Pelinescu-Onciul <andrei(a)iptel.org>
Date: Wed Oct 20 18:38:11 2010 +0200
tm: fix possible uninit. use of cancel_reason
In some cases an uninitialized cancel_reason structure was used
(e.g. fake_reply() and relay_reply() failing).
Reported-by: Alex Balashov abalashov evaristesys com
---
modules/tm/t_cancel.c | 1 +
modules/tm/t_reply.c | 11 +++++++++++
modules/tm/timer.c | 1 +
3 files changed, 13 insertions(+), 0 deletions(-)
diff --git a/modules/tm/t_cancel.c b/modules/tm/t_cancel.c
index 277c415..c1b52be 100644
--- a/modules/tm/t_cancel.c
+++ b/modules/tm/t_cancel.c
@@ -225,6 +225,7 @@ int cancel_branch( struct cell *t, int branch,
irb=&t->uac[branch].request;
irb->flags|=F_RB_CANCELED;
ret=1;
+ init_cancel_info(&tmp_cd);
# ifdef EXTRA_DEBUG
if (crb->buffer!=BUSY_BUFFER) {
diff --git a/modules/tm/t_reply.c b/modules/tm/t_reply.c
index fcf214d..382244f 100644
--- a/modules/tm/t_reply.c
+++ b/modules/tm/t_reply.c
@@ -1096,8 +1096,11 @@ static unsigned char drop_replies;
* Checks if the new reply (with new_code status) should be sent or not
* based on the current
* transaction status.
+ *
+ * @param cancel_data - initialized cancel_info structure.
* Returns - branch number (0,1,...) which should be relayed
* -1 if nothing to be relayed
+ * WARNING: cancel_data should be initialized prior to calling this function.
*/
static enum rps t_should_relay_response( struct cell *Trans , int new_code,
int branch , int *should_store, int *should_relay,
@@ -1576,6 +1579,10 @@ skip:
REPLY_LOCK and it returns unlocked!
If do_put_on_wait==1 and this is the final reply, the transaction
wait timer will be started (put_on_wait(t)).
+ *
+ * @param cancel_data - initialized cancel_info structure.
+ *
+ * WARNING: cancel_data should be initialized prior to calling this function.
*/
enum rps relay_reply( struct cell *t, struct sip_msg *p_msg, int branch,
unsigned int msg_status, struct cancel_info *cancel_data,
@@ -1851,6 +1858,10 @@ error01:
/* this is the "UAC" above transaction layer; if a final reply
is received, it triggers a callback; note well -- it assumes
it is entered locked with REPLY_LOCK and it returns unlocked!
+ *
+ * @param cancel_data - initialized cancel_info structure.
+ *
+ * WARNING: cancel_data should be initialized prior to calling this function.
*/
enum rps local_reply( struct cell *t, struct sip_msg *p_msg, int branch,
unsigned int msg_status, struct cancel_info *cancel_data)
diff --git a/modules/tm/timer.c b/modules/tm/timer.c
index a961675..a31a59c 100644
--- a/modules/tm/timer.c
+++ b/modules/tm/timer.c
@@ -303,6 +303,7 @@ static void fake_reply(struct cell *t, int branch, int code )
short do_cancel_branch;
enum rps reply_status;
+ init_cancel_info(&cancel_data);
do_cancel_branch = is_invite(t) && prepare_cancel_branch(t, branch, 0);
/* mark branch as canceled */
t->uac[branch].request.flags|=F_RB_CANCELED;
THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY.
A new Flyspray task has been opened. Details are below.
User who did this - Juha Heinanen (jh)
Attached to Project - sip-router
Summary - allow script variable as pdb_query() result parameter
Task Type - Improvement
Category - Module
Status - New
Assigned To -
Operating System - All
Severity - Medium
Priority - Normal
Reported Version - Development
Due in Version - Undecided
Due Date - Undecided
Details - currently second parameter of pdb_query(), which receives the query result, needs to be an avp. it should also be possible to use more efficient script variable ($var) as the query result parameter.
More information can be found at the following URL:
http://sip-router.org/tracker/index.php?do=details&task_id=94
You are receiving this message because you have requested it from the Flyspray bugtracking system. If you did not expect this message or don't want to receive mails in future, you can change your notification settings at the URL shown above.
Revision: 6046
http://openser.svn.sourceforge.net/openser/?rev=6046&view=rev
Author: miconda
Date: 2010-10-20 15:36:47 +0000 (Wed, 20 Oct 2010)
Log Message:
-----------
- version set to 1.5.5
Modified Paths:
--------------
branches/1.5/Makefile.defs
This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site.
Revision: 6045
http://openser.svn.sourceforge.net/openser/?rev=6045&view=rev
Author: henningw
Date: 2010-10-20 15:35:14 +0000 (Wed, 20 Oct 2010)
Log Message:
-----------
* update Changelog
Modified Paths:
--------------
branches/1.5/ChangeLog
This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site.
Revision: 6044
http://openser.svn.sourceforge.net/openser/?rev=6044&view=rev
Author: henningw
Date: 2010-10-20 15:32:23 +0000 (Wed, 20 Oct 2010)
Log Message:
-----------
* add Timo to changelog cfg
Modified Paths:
--------------
branches/1.5/doc/authors.xml
This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site.
Hello,
Based on our project policy to support officially the last two stable
branches, I was thinking of packaging kamailio 1.5.5 to mark its end.
New fixes will go to svn if it is the case, but no new release in 1.5.x
series will be done.
Also, since testing for 3.1.0 brought some fixes to 3.0.x, we should do
as well 3.0.4. My proposal is next week, Wednesday, Oct 20.
Don't forget to report issues you are aware for these two branches.
Cheers,
Daniel
--
Daniel-Constantin Mierla
http://www.asipto.com