I'm using the latest rtpengine master and still getting crashes once
every 1-2 days on a high call volume installation:
(gdb) where
#0 0x000000304e232925 in raise () from /lib64/libc.so.6
#1 0x000000304e234105 in abort () from /lib64/libc.so.6
#2 0x000000304e22ba4e in __assert_fail_base () from /lib64/libc.so.6
#3 0x000000304e22bb10 in __assert_fail () from /lib64/libc.so.6
#4 0x0000000000412d50 in stream_packet (fd=<value optimized out>, p=
0x7f1dcc1b1030, u=<value optimized out>) at call.c:547
#5 stream_fd_readable (fd=<value optimized out>, p=0x7f1dcc1b1030,
u=<value optimized out>) at call.c:819
#6 0x000000000040b4ce in poller_poll (p=0x10d3750,
timeout=<value optimized out>) at poller.c:354
#7 0x000000000040722d in poller_loop (d=0x10d3750) at main.c:542
#8 0x000000000040bb5f in thread_detach_func (d=<value optimized out>)
at aux.c:160
#9 0x000000304e6079d1 in start_thread () from /lib64/libpthread.so.0
#10 0x000000304e2e8b6d in clone () from /lib64/libc.so.6
Unfortunately, this packet capture is not very insightful. What's the
easiest way to build rtpengine with debug symbols so that some of these
values can be filled in?
--
Alex Balashov - Principal
Evariste Systems LLC
Tel: +1-678-954-0670
Web: http://www.evaristesys.com/, http://www.alexbalashov.com/
Please be kind to the English language:
http://www.entrepreneur.com/article/232906
Hello,
I want to announce the next Kamailio Development Workshop, to take place
in Paris, France, during July 9-10, 2014.
This event is the next in its series targeting to show the internals of
Kamailio and enable more people to become developers as well as let
users of Kamailio to get more knowledge about the design of the
application which can have relevant impact in operating deployment.
Be aware that it is not a workshop about Kamailio installation and
administration. Its content is about writing C code to extend Kamailio.
More details can be found at:
-
http://www.kamailio.org/w/2014/06/kamailio-development-workshop-july-9-10-2…
Similar to the past events, we are considering to have a social
networking event in the evening of July 9 (most probably a dinner meetup
at a nice place in Paris), which is open for everyone, each participant
taking care of own expenses.
Cheers,
Daniel
--
Daniel-Constantin Mierla - http://www.asipto.comhttp://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY.
The following task has a new comment added:
FS#445 - modules/tmx: t_is_failure_route() code or documentation is wrong
User who did this - Andrew Pogrebennyk (marduk)
----------
Thank you Daniel. I just tried it again. Not sure if I'm doing anything wrong, but t_is_failure_route() returns false when in branch route.
Call flow: when entering failure route, I do append_branch, from there I go to request route that does a few simple operations and arms branch route.
Jun 30 18:01:44 sp1 proxy[1116]: NOTICE: <script>: t_is_failure_route in failure route returned TRUE - R=sip:43991001@192.168.51.16 ID=8rhmFoEafzBBk9f9twwlw3ttEy3JImkU
Jun 30 18:01:44 sp1 proxy[1116]: NOTICE: <script>: t_is_failure_route in request route returned TRUE - R=sip:43991004@192.168.51.16 ID=8rhmFoEafzBBk9f9twwlw3ttEy3JImkU
Jun 30 18:01:44 sp1 proxy[1116]: NOTICE: <script>: t_is_failure_route in branch route returned FALSE - R=sip:43991004@192.168.51.16 ID=8rhmFoEafzBBk9f9twwlw3ttEy3JImkU
----------
More information can be found at the following URL:
http://sip-router.org/tracker/index.php?do=details&task_id=445#comment1534
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 - Joao Vitor Arruda (jarruda)
Attached to Project - sip-router
Summary - sca_call_info_update() function for 180 responses
Task Type - Bug Report
Category - Module
Status - Unconfirmed
Assigned To -
Operating System - All
Severity - High
Priority - Normal
Reported Version - 4.1
Due in Version - Undecided
Due Date - Undecided
Details - The actual code for sca_call_info_update() function in the SCA Module deal with 180 and 183 response codes in different ways:
https://github.com/kamailio/kamailio/blob/master/modules/sca/sca_call_info.…
- For 180 responses it will produce a NOTIFY with "appearance-state=alerting";
- For 183 responses it will produce a NOTIFY with "appearance-state=progressing";
Reading the attached "Broadworks SIP Access Side Extensions Interface Specifications, Release 13.0, version 1", which the module use as guide, it looks that both 180 and 183 should produce a NOTIFY with "appearance-state=progressing".
This document says:
The defined states are:
.....
Progressing = This appearance on the line is currently making an outgoing call.
Alerting = This appearance is receiving an incoming call.
.....
So when processing 180 and 183 responses it should use the same appearance-state (progressing) as it is dealing with responses for an outgoing call.
It was noticed that using the "wrong" appearance-state (alerting) when processing 180 responses will lead to problems with Polycom phones using firmware version 4.0.3 as the phones upon receiving the wrong appearance-state will change the display from "To:CalledExtension" to "From:CalledExtension" and record the call in the "Received Calls" instead of "Placed Calls".
The attached patch was produced to fix the actual code.
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=446
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#445 - modules/tmx: t_is_failure_route() code or documentation is wrong
User who did this - Daniel-Constantin Mierla (miconda)
----------
The error message is not related to t_is_failure_route(), but to the variable that gives the reply code associated with the transaction.
I committed a patch to deal with $T_reply_code in branch_route.
----------
More information can be found at the following URL:
http://sip-router.org/tracker/index.php?do=details&task_id=445#comment1533
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.