Revision: 5973
http://openser.svn.sourceforge.net/openser/?rev=5973&view=rev
Author: henningw
Date: 2010-02-02 16:52:14 +0000 (Tue, 02 Feb 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.
Hi, in most of my deployments I see myself adding xlog lines to imitate
an "access" log (like Apache/Nginx/Squid do).
Note that this is not the same as a CDR. Also, using xlog for this purpose
is not very cool as the logs are mixed with other logs generated by SR/Kamailio
itself (or its modules) as warnings, errors, other custom xlog's...
I'm reading a draft called "The Common Log File (CLF) format for SIP":
http://tools.ietf.org/html/draft-gurbani-sipping-clf
It seems really interesting for me and I'd love to have something similar in
SR/Kamailio.
The only "similar" approach would be using the siptrace module storing all
the SIP flows into database, however it's not recommended for scenarios with
high traffic.
An example of this kind of log would be the following (extracted from the
draft):
- Alice calls Bob.
- The proxy does parallel forking to two locations.
- Bob-1 replies 500.
- Bob-2 replies 200.
- Alice sends the ACK for the 200.
The common log generated by the proxy would look as follows:
------------------------------------------------------------------------
### Received request (server transaction):
1230756560 192.168.1.10 - INVITE sip:bob@example.net sip:alice@example.com;tag=hy7 sip:bob@example.net 7yhgt1(a)example.com - uyt67h FORK/-
### 100 replied upstream:
1230756560 uyt67h - 100 INVITE + -
# First INVITE generated by the proxy (client transaction):
1230756563 - - INVITE sip:bob@home.example.net sip:alice@example.com;tag=hy7 sip:bob@example.net 7yhgt1(a)example.com - uyt67h CLIENT/hb76
### Second INVITE generated by the proxy (client transaction):
1230756564 - - INVITE sip:bob@carphone.example.net sip:alice@example.com;tag=hy7 sip:bob@example.net 7yhgt1(a)example.com - uyt67h CLIENT/hb77
### Replies received from Bob-1 and Bob-2:
1230756565 uyt67h hb76 100 INVITE sip:bob@example.net;tag=876v -
1230756565 uyt67h hb77 100 INVITE sip:bob@example.net;tag=561t -
1230756565 uyt67h hb76 180 INVITE sip:bob@example.net;tag=876v -
1230756565 uyt67h hb77 180 INVITE sip:bob@example.net;tag=561t -
1230756567 uyt67h hb77 182 INVITE sip:bob@example.net;tag=561t -
1230756568 uyt67h hb76 500 INVITE sip:bob@example.net;tag=876v -
1230756568 uyt67h hb77 200 INVITE sip:bob@example.net;tag=561t "sip:bob@home.example.net"
### 200 replied upstream:
1230756569 uyt67h - 200 INVITE sip:bob@example.net;tag=561t "sip:bob@home.example.net"
### ACK sent to Bob-1 to acknoledge the 500 response:
1230756569 + - ACK sip:bob@home.example.net + + + - uyt67h CLIENT/hb76
### ACK received by the proxy and relayed to Bob-2:
1230756570 192.168.1.10 - ACK sip:bob@home.example.net sip:alice@example.com;tag=hy7 sip:bob@example.net;tag=76y 7yhgt1(a)example.com - t6y5 FORK/-
1230756570 - - ACK sip:bob@home.example.net sip:alice@example.com;tag=hy7 sip:bob@example.net;tag=76y 7yhgt1(a)example.com - t6y5 CLIENT/hb89
------------------------------------------------------------------------
Would make sense a SR module to achieve this purpose? Such module should
write these logs into a file (not syslog).
Regards.
--
Iñaki Baz Castillo <ibc(a)aliax.net>
Module: sip-router
Branch: master
Commit: ceb69ce0949d3e2f6ece2467cbce90b0255e057a
URL: http://git.sip-router.org/cgi-bin/gitweb.cgi/sip-router/?a=commit;h=ceb69ce…
Author: Elena-Ramona Modroiu <ramona(a)rosdev.ro>
Committer: Elena-Ramona Modroiu <ramona(a)rosdev.ro>
Date: Tue Feb 2 12:37:59 2010 +0100
mqueue: new module offering memory queues
- for usage in cfg file
- many queues can be defined
- one item in queue is a pair (key, value), both string
- functions to add and consume items in the queue
- fetching the oldest item makes it available to pseudo-variables
- example of usage: send tasks from SIP workers to a timer process
(e.g., defined by rtimer module) that consumes them. Can be some time
expensive operation, like email notification, etc.
---
modules/mqueue/Makefile | 12 +
modules/mqueue/README | 123 +++++++++++
modules/mqueue/doc/Makefile | 4 +
modules/mqueue/doc/mqueue.xml | 36 +++
modules/mqueue/doc/mqueue_admin.xml | 158 ++++++++++++++
modules/mqueue/mqueue_api.c | 408 +++++++++++++++++++++++++++++++++++
modules/mqueue/mqueue_api.h | 46 ++++
modules/mqueue/mqueue_mod.c | 208 ++++++++++++++++++
8 files changed, 995 insertions(+), 0 deletions(-)
Diff: http://git.sip-router.org/cgi-bin/gitweb.cgi/sip-router/?a=commitdiff;h=ceb…
Module: sip-router
Branch: kamailio_3.0
Commit: 229496c7170bcc85f517a4985f7ab4bad553c8d3
URL: http://git.sip-router.org/cgi-bin/gitweb.cgi/sip-router/?a=commit;h=229496c…
Author: Daniel-Constantin Mierla <miconda(a)gmail.com>
Committer: Daniel-Constantin Mierla <miconda(a)gmail.com>
Date: Tue Feb 2 13:23:03 2010 +0100
core: use one buffer for int2str
- static declaration inside ut.h function results in hard copy to many
places, affecting acc detection of int to str conversions in buffer
- reported by Alex Balashov
---
ut.c | 3 +++
ut.h | 13 ++++++++++---
2 files changed, 13 insertions(+), 3 deletions(-)
diff --git a/ut.c b/ut.c
index 7c63941..11d4fe7 100644
--- a/ut.c
+++ b/ut.c
@@ -42,6 +42,9 @@
#include "mem/mem.h"
#include "globals.h"
+/* global buffer for ut.h int2str() */
+char ut_buf_int2str[INT2STR_MAX_LEN];
+
/* converts a username into uid:gid,
* returns -1 on error & 0 on success */
diff --git a/ut.h b/ut.h
index 6861af7..3e4d7a6 100644
--- a/ut.h
+++ b/ut.h
@@ -292,10 +292,10 @@ static inline char* int2str_base(unsigned int l, int* len, int base)
-/* returns a pointer to a static buffer containing l in asciiz & sets len */
-static inline char* int2str(unsigned int l, int* len)
+/* print int to asciiz in a string buffer
+ * - be sure result buffer is at least INT2STR_MAX_LEN in size */
+static inline char* int2strbuf(unsigned int l, char *r, int* len)
{
- static char r[INT2STR_MAX_LEN];
int i;
i=INT2STR_MAX_LEN-2;
@@ -312,6 +312,13 @@ static inline char* int2str(unsigned int l, int* len)
return &r[i+1];
}
+extern char ut_buf_int2str[INT2STR_MAX_LEN];
+/* returns a pointer to a static buffer containing l in asciiz & sets len */
+static inline char* int2str(unsigned long l, int* len)
+{
+ return int2strbuf(l, ut_buf_int2str, len);
+}
+
/* Signed INTeger-TO-STRing: convers a long to a string
* returns a pointer to a static buffer containing l in asciiz & sets len */
static inline char* sint2str(long l, int* len)
Please don't commit any new features to master, only bug fixes and
documentation updates (they should go to sr_3.0, but for a short time
until everybody gets used to the new branch we will use both of them).
If you want to commit new features, please use another branch name,
either something under tmp/ or under <your_username>/ and we will merge
it into master once the freeze is over.
This freeze should last only a short time (maybe 1 week, we'll see how
things are going).
Andrei
Hello
When I try to do a push I get the following
error: file write error (No space left on device)
fatal: unable to write sha1 file
error: unpack failed: unpacker exited with error code
To ssh://mariuszbihlei@git.sip-router.org/sip-router
! [remote rejected] master -> master (n/a (unpacker error))
error: failed to push some refs to
'ssh://mariuszbihlei@git.sip-router.org/sip-router'
Any errors with git.sip-router.org ?!
Marius
I ran into a very interesting problem last night with 'acc' that took
me a few hours to solve, so I am posting my workaround for collective
benefit. It is probably not the cleanest and most appropriate
solution because I am not extensively familiar with the 'acc' code;
this is my first dive into it. Thus, I do not presume to submit an
actual patch.
The problem I had was that PVs read from the db_extra parameter that
had an internal type of integer (TYPE_INT) because of their lexical
scope were not being correctly evaluated, resulting in bizarre values
being put in the database.
I am using K 3.0.0 on 64-bit Xen guest running CentOS with
db_postgres. I did not check to see if this problem occurs with
db_mysql as I do not have MySQL anywhere nearby, but I don't believe
it is happening at the database layer anyhow. I also know this
problem was not present in 1.5.x, or several of my installations would
be non-functional; this must have something to do with use of new
'srdb1' stuff in the database side of 'acc', I hypothesise.
Anyway, the actual problem went like this. Let us say, for simplicity
of example, that I am using 'acc' with Postgres backing and have
something like this:
modparam("acc", "db_extra", "account_id=$avp(s:account_id)")
...
modparam("acc", "db_flag", 1)
What was happening was that if I did this in a request route:
$avp(s:account_id) = 42;
...
setflag(1);
if(!t_relay())
sl_reply_error();
exit;
Very strange and occasionally bizarre values, mostly duplicates of
other values I have in db_extra, would be written to acc.account_id (a
column of type 'integer') - at any rate, certainly not 42.
I enabled SQL statement logging on my PostgreSQL database to ensure
that the data being inserted was literally not 42, rather than this
being some sort of database-layer type conversion / representation
problem. Sure enough, it was true, although I also did notice that
'acc' encloses all inserted values in single quotes to be treated as
string literals. But this is immaterial, because RDBMs automatically
cast such input:
INSERT INTO acc (..., account_id) VALUES(..., '12');
Now, I could fix the problem by simply assigning the AVP a string
literal instead:
$avp(s:account_id) = '42';
Now the data was inserted normally.
I also tested with user variables ($var(...)) and the same was true,
so the problem is not AVP-specific. Also, all other evaluative
contexts for PVs with these values work fine, such as printing them.
The problem does not seem to be with 'db_postgres', neither with 'pv',
nor with 'avpops' -- it is particular to 'acc'.
After some hours of investigation I found that what was happening is
that the type of the PV being referenced is not being correctly packed
into the various arrays populated by extra2strar() in
modules_k/acc/acc_extra.c, and thus was being misread when iterated in
acc_db_request() in modules_k/acc/acc.c. Specifically, this check was
inadequate:
if (value.rs.s+value.rs.len==static_detector) {
val_arr[n].s = int_buf +
r*INT2STR_MAX_LEN;
val_arr[n].len = value.rs.len;
memcpy(val_arr[n].s, value.rs.s,
value.rs.len);
r++;
LM_INFO("New int tenant: %s\n",
val_arr[n].s);
} else {
val_arr[n] = value.rs;
LM_INFO("New str tenant: %s\n",
value.rs);
}
In my debugging, all PV values were showing up as "New str tenant"
regardless of whether they were natively integers, and regardless of
what the PV spec type was actually set to. The type was set correctly
on the PV spec, so of course the integer value got stored correctly in
int_var[] below:
if (value.flags&PV_VAL_INT) {
int_arr[n] = value.ri;
type_arr[n] = TYPE_INT;
} else {
type_arr[n] = TYPE_STR;
}
... but since 'acc' wants to treat all extra values as strings, this
was not sufficient, because what was failing was this condition:
if (value.rs.s+value.rs.len==static_detector)
I guess value.rs.s in case of the PV value being PV_VAL_INT is not
null terminated properly? This I truly do not know.
In any event, I just added a check on the PV flags to see if it is an
integer value and this fixed my problem:
if (value.rs.s+value.rs.len==static_detector
|| value.flags & PV_VAL_INT) {
... however, I do not know that this was the most insightful solution.
This is rather critical I think, because it means anyone trying to
store PV values that are initialised with a natively numerical type in
script (or extracted as a numerical value from a database, e.g.
sql_query("SELECT account_id::integer FROM table ..."), I found this
to be a problem as well) cannot store them in the database reliably
using 'db_extra'.
Thanks!
--
Alex Balashov - Principal
Evariste Systems LLC
Tel : +1 678-954-0670
Direct : +1 678-954-0671
Web : http://www.evaristesys.com/
I am cc-ing sr-dev, since tcp code is from ser and Andrei may have more
insights...
On 1/28/10 2:41 PM, Aymeric Moizard wrote:
>
>
> On Thu, 28 Jan 2010, Henning Westerholt wrote:
>
>> On Thursday 28 January 2010, Aymeric Moizard wrote:
>>> here is the backtrace I have. unfortunatly without debug symbol!
>>> I found the same for many of the kamailio process. "sched_yield"
>>> is pending for ever. My system is a debian/etch.
>>>
>>> #0 0xffffe424 in __kernel_vsyscall ()
>>> #1 0xb7cef4ac in sched_yield () from /lib/tls/i686/cmov/libc.so.6
>>> #2 0x080a93fd in tcp_send ()
>>> #3 0xb7975679 in send_pr_buffer () from
>>> /usr/lib/kamailio/modules/tm.so
>>> #4 0xb79789ac in t_forward_nonack () from
>>> /usr/lib/kamailio/modules/tm.so
>>> #5 0xb7974784 in t_relay_to () from /usr/lib/kamailio/modules/tm.so
>>> #6 0xb7983a11 in load_tm () from /usr/lib/kamailio/modules/tm.so
>>> #7 0x081cf810 in mem_pool ()
>>> #8 0x00000000 in ?? ()
>>>
>>> I guess most t_relay operation towards my "mobipouce.com" domain
>>> with one IP being down breaks each kamailio process one after the
>>> other... I'm not sure every such t_relay operation is always breaking
>>> exactly one thread each time.
>>>
>>> I went through the lock/unlock of tcp_main.c but it seems every
>>> lock has an unlock at least...
>>
>> Hi Aymeric,
>>
>> i remember that we observed this "sched_yield" problems on one old
>> 0.9 system
>> after some time (like weeks or month). We did not found the solution
>> in this
>> case, after a restart it was gone again..
>>
>> You mentioned in an earlier mail that you see this related to UDP
>> traffic, but
>> in the log file and also in your investigations you think its related
>> to TPC?
>
> This is the exact case:
> 1-> SUBSCRIBE sent to/received by over UDP to kamailio.
> 2-> kamailio does a SRV record lookup for "mobipouce.com"
> 3-> kamailio try sip2.mobipouce.com (91.199.234.47) over TCP first
> 4-> connection failed with logs:
> Jan 27 12:56:38 ns26829 /usr/sbin/kamailio[9763]:
> ERROR:core:tcp_blocking_connect: poll error: flags 18
> Jan 27 12:56:38 ns26829 /usr/sbin/kamailio[9763]:
> ERROR:core:tcp_blocking_connect: failed to retrieve SO_ERROR (111)
> Connection refused
> Jan 27 12:56:38 ns26829 /usr/sbin/kamailio[9763]:
> ERROR:core:tcpconn_connect: tcp_blocking_connect failed
> Jan 27 12:56:38 ns26829 /usr/sbin/kamailio[9763]: ERROR:core:tcp_send:
> connect failed
> Jan 27 12:56:38 ns26829 /usr/sbin/kamailio[9763]: ERROR:tm:msg_send:
> tcp_send failed
> Jan 27 12:56:38 ns26829 /usr/sbin/kamailio[9763]:
> ERROR:tm:t_forward_nonack: sending request failed
> 5-> I guess kamailio is supposed to try other SRV record value:
> sip2.mobipouce.com (91.199.234.46) but it doesn't
>
> Thus, I'm guessing the issue is related to SRV record with failover OR
> just tcp failure. Not related to UDP at all.
so TCP connect failed, the tcp worker returned as it prints the message
and, to be sure I got it right, the UDP worker (the one that received)
got blocked?
>
> It's definitly possible to reproduce the issue now!
>
> I guess anyone can try your version of kamailio and t_relay message
> to "mobipouce.com" and you'll fall in that case! Sending plenty of
> those messages will finally lock all kamailio process.
All? tcp and udp?
Cheers,
Daniel
>
> Regards,
> Aymeric MOIZARD / ANTISIP
> amsip - http://www.antisip.com
> osip2 - http://www.osip.org
> eXosip2 - http://savannah.nongnu.org/projects/exosip/
>
>
>> Regards,
>>
>> Henning
>>
>> Viele Grüße,
>>
>> Henning
>>
>
> _______________________________________________
> Kamailio (OpenSER) - Users mailing list
> Users(a)lists.kamailio.org
> http://lists.kamailio.org/cgi-bin/mailman/listinfo/users
> http://lists.openser-project.org/cgi-bin/mailman/listinfo/users
--
Daniel-Constantin Mierla
* http://www.asipto.com/
