THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY.
The following task has a new comment added:
FS#170 - get_body_part2 (parse_body)
User who did this - Daniel-Constantin Mierla (miconda)
----------
There seems to be an issue in function:
+int part_multipart_headers_cmp (char *buffer,
+ char *end_buffer,
+ unsigned short content_type,
+ unsigned short content_subtype,
+ char *content_id,
+ char *content_length)
+{
+ int error = 0;
+ char *error_msg = NULL;
+
+ char *cpy_c = NULL;
+ char *cpy_d = NULL;
+
+ char *value_ini = NULL;
+ char *value_fin = NULL;
+ unsigned int umime;
+
+ int found = 0;
+ int found_content_type = 0;
+ int found_content_id = 0;
+ int found_content_length = 0;
+
+ if ((buffer == NULL) || (end_buffer == NULL)) {
+ error = -1;
+ error_msg = "buffer and/or end_buffer are NULL";
+ } else {
+ *cpy_c = buffer;
+ *cpy_d = end_buffer;
cpy_c and cpy_d are initialized to NULL, but then values are stored at that address (the last two lines above). Did you want to have:
+ cpy_c = buffer;
+ cpy_d = end_buffer;
----------
More information can be found at the following URL:
https://sip-router.org/tracker/index.php?do=details&task_id=170#comment776
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.
Hi!
Looking at the modules/snmpstats/snmpstats.c table over response codes, it's fairly old. I have updated it to the latest list from IANA - but the question is if this is considered a bug fix that can be committed to 4.0.0.
I think so - do you?
/O
Dear All,
I am trying to use Kamailio 3.1.x server (called LB here) as the Load
Balancer for two other Kamailio server (called server01 and server02 here) .
Client A -----> Kamailio LB -----> Kamailio server01
Client B -----> Kamailio LB -----> Kamailio server01
If I dont use LB here , and letting Client A and B connect to Kamailio
server01 directly , all the communication is fine.
While using Kamailio LB ,without luck, although the sip client A and B
get 200 from server01 for Register,
they cannot reach each other for "Message" and "Invite".
It will be great appreciated if anyone can give a hint.
my config for Kamailio LB is as below :
==========================================
....
debug=2 # debug level (cmd line: -dddddddddd)
fork=yes
log_stderror=yes # (cmd line: -E)
children=2
check_via=no # (cmd. line: -v)
dns=off # (cmd. line: -r)
rev_dns=off # (cmd. line: -R)
port=5060
# for more info: sip_router -h
# ------------------ module loading ----------------------------------
mpath="/usr/local/lib64/kamailio/modules_k/:/usr/local/lib64/kamailio/modules/"
loadmodule "sl.so"
loadmodule "tm.so"
loadmodule "rr.so"
loadmodule "maxfwd.so"
loadmodule "usrloc.so"
loadmodule "registrar.so"
loadmodule "textops.so"
loadmodule "mi_fifo.so"
loadmodule "dispatcher.so"
loadmodule "db_mysql.so"
# ----------------- setting module-specific parameters ---------------
# -- dispatcher params --
modparam("mi_fifo", "fifo_name", "/tmp/openser_fifo")
modparam("dispatcher", "db_url","mysql://.........@........")
modparam("usrloc", "db_mode", 0)
modparam("rr", "enable_full_lr", 1)
route{
if (!mf_process_maxfwd_header("10")) {
sl_send_reply("483","Too Many Hops");
exit;
};
# if (!method=="REGISTER")
# record_route();
ds_select_dst("1","4");
forward();
exit;
}
..
==========================================
best regards,
chanea
Hi!
I've spent five days at SIPit 30 testing Kamailio on a tiny Asus EEE-netbook. It's been great, and apart from the bug hitting me while using outbound, we've done great in all tests.
During the proxy doom test today, the netbook processed way over 50.000 messages in a single INVITE transaction that spiralled and looped and behaved in funny ways, and the CPU still had a lot of power to do other things. The hub we used was the limiting factor.
Kamailio 4.0.0 beta was involved in all multiparty tests, from TLS and RTCweb to forking, spiralling and proxy doom. We proved that we have a solid product that can handle all kind of scenarious, even TCP overflow attacks.
Thanks for all the help over jabber, IRC and other means!
Special thank you to Fred Posner who contributed a Big Fred Cookie!
Have a great weekend!
/O
Module: sip-router
Branch: master
Commit: 7952711e6079e02a07ad027c6d8840e755c6e528
URL: http://git.sip-router.org/cgi-bin/gitweb.cgi/sip-router/?a=commit;h=7952711…
Author: Olle E. Johansson <oej(a)edvina.net>
Committer: Olle E. Johansson <oej(a)edvina.net>
Date: Sun Feb 24 10:25:38 2013 +0100
snmpstats fix typo
---
modules/snmpstats/snmpstats.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/modules/snmpstats/snmpstats.c b/modules/snmpstats/snmpstats.c
index 0fa7830..26240d8 100644
--- a/modules/snmpstats/snmpstats.c
+++ b/modules/snmpstats/snmpstats.c
@@ -49,7 +49,7 @@
* 4) mod_init() will initialize some interprocess communication buffers, as
* well as callback mechanisms for the usrloc module. To understand what the
* interprocess buffer and callbacks are and are for, please see the comments
- * at the beginning of kamailioSIPRegUserTable.c
+ * at the beginning of snmpSIPRegUserTable.c
*/
/*!