Hello,
compiling sca module rises next warning:
sca_call_info.c: In function ‘sca_call_info_update’:
sca_call_info.c:1977:7: warning: the comparison will always evaluate as
‘true’ for the address of ‘call_info’ will never be NULL [-Waddress]
sca_call_info.c:1984:14: warning: the comparison will always evaluate as
‘true’ for the address of ‘call_info’ will never be NULL [-Waddress]
The lead to the next define, which does not seem right at first sight
#define SCA_CALL_INFO_EMPTY( ci1 ) \
((ci1) != NULL || \
((ci1)->index == SCA_CALL_INFO_APPEARANCE_INDEX_ANY && \
(ci1)->state == SCA_APPEARANCE_STATE_UNKNOWN))
Either first condition has to be ==NULL or the || has to be relaplced by
&&. Otherwise, if stays like now, if ci1==NULL, will result in a crash,
by accessing ->index and ->state of a null pointer.
Cheers,
Daniel
--
Daniel-Constantin Mierla - http://www.asipto.comhttp://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
Kamailio Advanced Trainings - Berlin, Nov 25-28
- more details about Kamailio trainings at http://www.asipto.com -
THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY.
A new Flyspray task has been opened. Details are below.
User who did this - Víctor Seva (linuxmaniac)
Attached to Project - sip-router
Summary - modules/app_lua: sr.xavp.get() allow get all values of a name
Task Type - Improvement
Category - Module
Status - New
Assigned To - Víctor Seva
Operating System - All
Severity - Low
Priority - Normal
Reported Version - Development
Due in Version - Undecided
Due Date - Undecided
Details - Use value indx<0 to be able to get all the values of a xavp in the lua table
One or more files have been attached.
More information can be found at the following URL:
https://sip-router.org/tracker/index.php?do=details&task_id=365
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.
THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY.
The following task has a new comment added:
FS#311 - Patch to Add s.urlencode.param
User who did this - Josh (JoshE)
----------
Whoops. I picked this up accidentally when I generated the patch. That is for a whole different issue.
I modified dispatch to return the attribute value to the column, which I use to store a value I want to use in my routing process. It's a simple patch. If anyone else wants t be able to use AVP_DSATTRS after a ds_is_from_list call, you can definitely patch for it.
----------
More information can be found at the following URL:
http://sip-router.org/tracker/index.php?do=details&task_id=311#comment1159
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.
THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY.
A new Flyspray task has been opened. Details are below.
User who did this - Josh (JoshE)
Attached to Project - sip-router
Summary - Crash in TCP Read on Kamailio 4.0.1
Task Type - Bug Report
Category - Core
Status - Unconfirmed
Assigned To -
Operating System - All
Severity - Critical
Priority - Normal
Reported Version - 4.0
Due in Version - Undecided
Due Date - Undecided
Details - I am seeing a crash in TCP Read using the HTTP module. Here's the backtrace:
(gdb)
#0 qm_detach_free (frag=0x7f7556ce5640, qm=<optimized out>) at mem/q_malloc.c:269
#1 qm_malloc (qm=0x7f7556b1c010, size=64) at mem/q_malloc.c:386
#2 0x000000000059515e in parse_headers (msg=0x7f7556bb7eb0, flags=<optimized out>, next=<optimized out>) at parser/msg_parser.c:343
#3 parse_msg (buf=<optimized out>, len=<optimized out>, msg=0x7f7556bb7eb0) at parser/msg_parser.c:650
#4 0x0000000000501b2c in receive_msg (
buf=0x7f75501f98e8 "POST /RPC2 HTTP/1.1\r\nHost: ord-proxy-1.domain.com\r\nUser-Agent: Httpful/0.1.7 (cURL/7.21.7 PHP/5.4.14 (Linux) nginx/1.4.3 Mozilla/5.0 (compatible; MSIE 10.0; Windows NT 6.1; WOW64; Trident/6.0))\r\n"..., len=418, rcv_info=0x7f75501f9618) at receive.c:144
#5 0x000000000054b652 in tcp_read_req (con=0x7f75501f9600, bytes_read=0x7fffbf8bcc50, read_flags=0x7fffbf8bcc60) at tcp_read.c:1398
#6 0x000000000054c7a3 in handle_io (fm=<optimized out>, events=<optimized out>, idx=<optimized out>) at tcp_read.c:1570
#7 0x000000000054f78a in io_wait_loop_epoll (repeat=<optimized out>, h=<optimized out>, t=<optimized out>) at io_wait.h:1092
#8 tcp_receive_loop (unix_sock=<optimized out>) at tcp_read.c:1739
#9 0x0000000000489862 in tcp_init_children () at tcp_main.c:4969
#10 0x00000000004c1866 in main_loop () at main.c:1723
#11 0x000000000041b5d6 in main (argc=<optimized out>, argv=<optimized out>) at main.c:2566
Full backtrace is attached.
Has anyone run across this before?
One or more files have been attached.
More information can be found at the following URL:
http://sip-router.org/tracker/index.php?do=details&task_id=364
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.
Hello,
(Sorry for cross-posting to -users and -dev; not really sure where this
post belongs most.)
A few days ago, I ran into an issue with a Kamailio server being
somewhat unresponsive, during moderate call volume, on account of a
down rtpproxy--the only rtpproxy in the set. This is rtpproxy classic,
not ngcp-mediaproxy-ng.
Rtpproxy was not actually engaged on any of the initial INVITEs going
through the server; the server is configured to invoke it conditionally
based on a setting, and the setting was not set for any endpoints.
rtpproxy_manage() was never called.
However, I call unforce_rtp_proxy() unconditionally in my config when
handling CANCELs, reasoning that it can't do any harm if
rtpproxy_manage() was not called before[1].
Nevertheless, it seemed to be the case that this situation was clogging
up SIP worker threads, because some SIP messages were definitely
dropped. Periodic log messages about inability to reach the rtpproxy
were echoed as well. This problem cleared up almost immediately when
the rtpproxy instance was restored into service.
This raised some questions in my mind about the relationship between
rtpproxy management and SIP worker thread utilisation. I assume it was
my indiscriminate unforce_rtp_proxy() calls that were actually clogging
up the worker threads, right? If so, why? I figured that in the
unforce_rtp_proxy() case, the rtpproxy module simply sends
fire-and-forget UDP messages down the UDP control socket without any
sort of blocking for acknowledgement, since in this case the call must
be released on the rtpproxy side without doing any rewriting of SDP on
the Kamailio side (unlike in the case where rtpproxy is engaged). Thus,
there should be no need to wait for ports to substitute into the
message. Or is the same response-wait mechanism used regardless, even
in the unforce_rtp_proxy() case, for programmatic reasons?
More broadly, is there any way that this scenario can be prevented? In
other words, is there a way to work around an outage of all rtpproxies
in the set without tying up workers, or at least tying them up less
severely?
Thanks!
-- Alex
[1] Is this a reasonable assumption?
The reason I do this is that I don't see a way to find out if
rtpproxy was engaged from the body of a CANCEL message. I do check
for a ;proxy_media RR parameter when handling BYEs, but since a
CANCEL is not an in-dialog request, I'm not sure what to do except
to call unforce_rtp_proxy()/rtpproxy_manage() indiscriminately,
without resorting to storing state in htable or other complications
I don't want.
--
Alex Balashov - Principal
Evariste Systems LLC
235 E Ponce de Leon Ave
Suite 106
Decatur, GA 30030
United States
Tel: +1-678-954-0670
Web: http://www.evaristesys.com/, http://www.alexbalashov.com/
THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY.
A new Flyspray task has been opened. Details are below.
User who did this - i (takeshi)
Attached to Project - sip-router
Summary - Errors in snmpstats KAMAILIO-TC
Task Type - Bug Report
Category - Module
Status - Unconfirmed
Assigned To -
Operating System - All
Severity - Low
Priority - Normal
Reported Version - Development
Due in Version - Undecided
Due Date - Undecided
Details - When I use snmpget to get snmpstats, I get this:
[root@LAB002185-FLIP-SERVER SIP-Trunking]# snmpget -v2c -c public 192.168.2.185 kamailioCurNumDialogs.0
2013-11-06 21:07:46 Expected "(" (_): At line 65 in /usr/share/snmp/mibs/KAMAILIO-TC
2013-11-06 21:07:46 Bad operator ((): At line 65 in /usr/share/snmp/mibs/KAMAILIO-TC
2013-11-06 21:07:46 Did not find 'KamailioSIPMethodIdentifier' in module KAMAILIO-TC (/usr/share/snmp/mibs/KAMAILIO-SIP-COMMON-MIB.txt)
2013-11-06 21:07:46 Did not find 'KamailioSIPEntityRole' in module KAMAILIO-TC (/usr/share/snmp/mibs/KAMAILIO-SIP-COMMON-MIB.txt)
2013-11-06 21:07:46 Did not find 'X731UsageState' in module KAMAILIO-TC (/usr/share/snmp/mibs/KAMAILIO-MIB.txt)
2013-11-06 21:07:46 Did not find 'X731AlarmStatus' in module KAMAILIO-TC (/usr/share/snmp/mibs/KAMAILIO-MIB.txt)
2013-11-06 21:07:46 Did not find 'X731AlarmState' in module KAMAILIO-TC (/usr/share/snmp/mibs/KAMAILIO-MIB.txt)
KAMAILIO-MIB::kamailioCurNumDialogs.0 = Gauge32: 0
The command doesn't fail, as data is reported correctly, but the error messages are annoying.
I compared, KAMAILIO-TC with the old OPENSER-TC, and found some issues.
I have created a patch (see attachment) for commit:
0fbdb8cf7a7687d6ecc8049dfdcb1244abd726af
After that, it works as expected:
[root@LAB002185-FLIP-SERVER SIP-Trunking]# snmpget -v2c -c public 192.168.2.185 kamailioCurNumDialogs.0
KAMAILIO-MIB::kamailioCurNumDialogs.0 = Gauge32: 0
Obs: my only doubt is about the line for --sctp_tls(5).
I am just commenting it to disable it (the problem is that the parser doesn't like the underscore in the word) but maybe it must be corrected differently.
One or more files have been attached.
More information can be found at the following URL:
http://sip-router.org/tracker/index.php?do=details&task_id=363
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.