THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY.
A user has added themself to the list of users assigned to this task.
FS#122 - Kamailio 3.1.3 crash
User who did this - Jasmin Schnatterbeck (jasmin)
http://sip-router.org/tracker/index.php?do=details&task_id=122
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#118 - db_mysql fails to load on centos 5 due to bad simbol ref
User who did this - Daniel-Constantin Mierla (miconda)
----------
I committed a patch to Makefile for db_mysql in order to use mysql_config tool to detect needed libs to link against. Can you check if it work now for you with latest version (branches master or 3.1)? Thanks.
----------
More information can be found at the following URL:
http://sip-router.org/tracker/index.php?do=details&task_id=118#comment172
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.
Daniel-Constantin Mierla has taken ownership of the following task:
FS#118 - db_mysql fails to load on centos 5 due to bad simbol ref
More information can be found at the following URL:
http://sip-router.org/tracker/index.php?do=details&task_id=118
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 Jason,
i'll be in London Thursday through Sunday, so i will just have time to
review your changes on Monday... so take your time!
A Zip-File would be great...
Carsten
2011/4/6 Jason Penton <jason.penton(a)gmail.com>:
> Hey Carsten
> Sounds great. Yes I have seen activity on the Rf interface from Fraunhofer.
> At the moment we are testing our Ro interface after which I will add an API
> to it so it can be called from, for example the dialog module. Right now we
> only send the START CCR request from the cfg file and all looks good. Should
> have some code for you to review before the end of this week.
> Should I just zip the module code up and send to you?
> Cheers
> Jason
>
> On Tue, Apr 5, 2011 at 6:16 PM, Carsten Bock <lists(a)bock.info> wrote:
>>
>> Hi Jason,
>>
>> that would be great!
>> Did you notice? Fraunhofer Institute is currently working on an Rf
>> Interface in the S-CSCF...
>> I wanted to implement the Ro-Interface in the S-CSCF myself (as a step
>> 3), but if you want to do it, go ahead!
>> My focus is currently on the described developments (first on
>> implementation of RFC 3680 in Kamailio, then the replacement of the
>> built-in usrloc within the P-CSCF).
>> i would feel more comfortable, if i could review your code first,
>> before i add it to the official Kamailio/sip-router repository....
>> would that be ok for you?
>>
>> Thanks for your support,
>> Carsten
>>
>> 2011/4/5 Jason Penton <jason.penton(a)gmail.com>:
>> > Hi Carsten,
>> > in light of Daniel's response maybe we should join forces? how would you
>> > feel about me contributing the effort you are putting into openims and
>> > sr3?
>> > btw, I have already written a module for the Ro interface. What I wanted
>> > to
>> > do next was to incorp. code into the dialog module to be able to support
>> > online charging through the Ro interface.
>> > thoughts?
>> > Cheers
>> > jason
>> >
>> > On Tue, Apr 5, 2011 at 2:06 PM, Daniel-Constantin Mierla
>> > <miconda(a)gmail.com>
>> > wrote:
>> >>
>> >> Hello,
>> >>
>> >> On 4/5/11 1:35 PM, Carsten Bock wrote:
>> >>>
>> >>> Hi,
>> >>>
>> >>> I will simply forward this question...
>> >>> I would suppose to put it somewhere at the Kamailio SVN for 1.5?
>> >>
>> >> 1.5 is no longer maintained officially, just backports by developers
>> >> that
>> >> still use it -- which may happen down to 0.9 -- but no new features.
>> >>
>> >> Personally I would prefer to go only with one IMS extensions
>> >> integration,
>> >> based on current development branch (git master). Besides the fact that
>> >> joining forces will make things move forward faster, having two
>> >> directions
>> >> for same thing (one within very old branch) will confuse people a lot.
>> >> Maybe
>> >> Jason will consider trying 3.1.x and we can try removing his doubts
>> >> about
>> >> this version when he has specific questions about what he does not
>> >> trust.
>> >>
>> >> I strongly think this is the best at this moment, there is already
>> >> confusion with duplicated modules coming from kamailio and ser,
>> >> creating a
>> >> new development branch based on 1.5 will confuse even more. We are
>> >> working
>> >> to remove duplicated, thus remove confusion, and we should go only in
>> >> this
>> >> direction if we want to finish it soon.
>> >>
>> >> Now regarding the trust of 3.x, I can say that 3.1.x is far more better
>> >> than 1.5. In 1.x one could barely use tcp or tls, the tm module had
>> >> some
>> >> potential races which couldn't be handled without a major
>> >> refurbishment.
>> >> That happened in 3.x - if one search the recent archive, there were
>> >> crashes
>> >> reported to 1.5 rather than to 3.1.
>> >>
>> >> If one does not like the mix of kamailio and ser modules, then just
>> >> ignore
>> >> the modules_s/* for a while and you are set. Installing kamailio from
>> >> packages take care of that and only kamailio modules are installed
>> >> (modules/* and modules_k/*). AFAIK, the openimscore developers are
>> >> working
>> >> also with 3.x so future code from them will just work on latest version
>> >> of
>> >> our project.
>> >>
>> >> Cheers,
>> >> Daniel
>> >>
>> >>> Carsten
>> >>>
>> >>> ---------- Forwarded message ----------
>> >>> From: Jason Penton<jason.penton(a)gmail.com>
>> >>> Date: 2011/4/5
>> >>> Subject: Re: [OpenIMSCore-CSCF] About my "carstenbock/ims" branch on
>> >>> the sip-router.org GIT repository
>> >>> To: Carsten Bock<carsten(a)ng-voice.com>
>> >>> Cc: openimscore-cscf(a)lists.berlios.de
>> >>>
>> >>>
>> >>> Hey Carsten,
>> >>> Right now I am doing something similar, but rather with
>> >>> kamailio-1.5.5. I have not migrated to SR yet and dont intend to
>> >>> anytime soon. Right now I have ported CDP, CDP_AVP, and ICSCF and they
>> >>> are running.
>> >>> My reason is that I don't quite 'trust' sr2 just yet - and I'm not
>> >>> sure I like the mix and match of ser and kamailio modules - anyway a
>> >>> discussion probably already discussed and not for this thread. I'd be
>> >>> happy to put a 1.5.5 version up somewhere that everyone could use?
>> >>> what do you suggest?
>> >>> Cheers
>> >>> Jason
>> >>>
>> >>> On Tue, Apr 5, 2011 at 12:30 PM, Carsten Bock<carsten(a)ng-voice.com>
>> >>> wrote:
>> >>>>
>> >>>> Hi everyone,
>> >>>>
>> >>>> i just wanted to notice, that i am actually working on re-integrating
>> >>>> the OpenIMS-core into the sip-router.org/Kamailio project.
>> >>>> It is not a fork of the official OpenIMSCore project, but more a
>> >>>> merge
>> >>>> of the OpenIMScore Project into the Kamailio/sip-router.org project.
>> >>>>
>> >>>> As a first step, i've made all the CSCF modules compile and work with
>> >>>> a current Kamailio source. In order to do this, only minor adaptions
>> >>>> were required.
>> >>>>
>> >>>> As a second step, i am working on a better integration into the
>> >>>> existing structures of the Kamailio project; i want to achieve the
>> >>>> following things:
>> >>>> - replace integrated dialog awareness of the CSCF modules with
>> >>>> Kamailio's dialog module
>> >>>> - replcae integrated registrar of the CSCF modules with Kamailio's
>> >>>> registrar module
>> >>>> - replace integrated nathelper support with the sip-router.org
>> >>>> nathelper/rtpproxy moduels
>> >>>> - replcae integrated RFC 3680 support with Kamailio's
>> >>>> Presence/Presence-User-Agent modules
>> >>>> - add documentation in accordance with the other sip-router.org
>> >>>> modules
>> >>>>
>> >>>> I've already changed quite a few things in the Kamailio core, in
>> >>>> order
>> >>>> to achieve this: K's dialog module is now able to store additional
>> >>>> data to a dialog (works great), K's usrloc/registrar module is able
>> >>>> to
>> >>>> store additional information to an contact (still buggy) and i have
>> >>>> already added support for RFC 3680 to Kamailio's presence/pua
>> >>>> infrastructure (when you register, the system will "PUBLISH" the
>> >>>> registration state; another system may already "SUBSCRIBE" to the
>> >>>> status and "NOTIFY" requests are already parsed (but not stored
>> >>>> yet)).
>> >>>> So it is going on. I have also already modified some of the config to
>> >>>> use generic append_hf() and remove_hf() functions instead of custom
>> >>>> implemented functions...
>> >>>>
>> >>>> The progress is slow but steady since i work on it apart from my
>> >>>> regular work. I try to publish any new developments on this on my
>> >>>> blog/homepage (www.ng-voice.com), where you may also find some more
>> >>>> information about the installation and the components of the project
>> >>>> (i provide a repository of the last step for easy installation).
>> >>>>
>> >>>> I started implementing an own HSS some time ago (openhss.org), but
>> >>>> the
>> >>>> development on this currently stopped. First, i do not have enough
>> >>>> time to work on both the Kamailio integration, regular work and the
>> >>>> HSS; second the main developer on the HSS (Brian) just resigned due
>> >>>> to
>> >>>> health reasons.
>> >>>>
>> >>>> Some of you may have noticed, that i am working for Telefonica in
>> >>>> Germany as a regular work. I am working on the Class 4/5
>> >>>> infrastructure at Telefonica and we have already implemented an
>> >>>> Ericsson IMS core. However, i wanted to mention, that neither
>> >>>> Telefonica nor O2 is behind this project. The only support i get from
>> >>>> Telefonica is, that i get a monthly salary and that i may use some
>> >>>> time to work on the OpenIMS-project during normal office-hours (as
>> >>>> time allows).
>> >>>> If i do things, i do it by heart and not half-hearted... that
>> >>>> probably
>> >>>> explains a lot of the effort spent on the project.
>> >>>>
>> >>>> Kind regards,
>> >>>> Carsten
>> >>>>
>> >>>> --
>> >>>> Carsten Bock
>> >>>> http://www.ng-voice.com
>> >>>> mailto:carsten@ng-voice.com
>> >>>>
>> >>>> Schomburgstr. 80
>> >>>> 22767 Hamburg
>> >>>> Germany
>> >>>>
>> >>>> Mobile +49 179 2021244
>> >>>> Office +49 40 34927219
>> >>>> Fax +49 40 34927220
>> >>>> _______________________________________________
>> >>>> OpenIMSCore-CSCF mailing list
>> >>>> OpenIMSCore-CSCF(a)lists.berlios.de
>> >>>> https://lists.berlios.de/mailman/listinfo/openimscore-cscf
>> >>>
>> >>>
>> >>>
>> >>
>> >> --
>> >> Daniel-Constantin Mierla
>> >> http://www.asipto.com
>> >>
>> >
>> >
>>
>>
>>
>> --
>> Carsten Bock
>> http://www.ng-voice.com
>> mailto:carsten@ng-voice.com
>
>
--
Carsten Bock
http://www.ng-voice.com
mailto:carsten@ng-voice.com
THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY.
The following task has a new comment added:
FS#121 - Fault upon UA registration
User who did this - Daniel-Constantin Mierla (miconda)
----------
Did you get a coredump? If yes, send the backtrace:
gdb /path/to/kamailio /path/to/corefile
bt
If not, be sure you set 'ulimit -c unlimited'
Alternatively, run kamailio with 'debug=3' and send all the logs from the moment REGISTER is received. If you can ngrep the REGISTER request and paste it here, would be very useful.
----------
More information can be found at the following URL:
http://sip-router.org/tracker/index.php?do=details&task_id=121#comment171
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.
Daniel-Constantin Mierla has taken ownership of the following task:
FS#121 - Fault upon UA registration
More information can be found at the following URL:
http://sip-router.org/tracker/index.php?do=details&task_id=121
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 - Mike Thomas (mthomasslo)
Attached to Project - sip-router
Summary - Fault upon UA registration
Task Type - Bug Report
Category - Core
Status - Assigned
Assigned To - Andrei Pelinescu-Onciul
Operating System - Linux
Severity - Medium
Priority - Normal
Reported Version - 3.1
Due in Version - Undecided
Due Date - Undecided
Details - When a UA (in this case an Aastra IP Phone) attempts to register, core crashes and logs "BUG: del_lump: offset exceeds message size (357720 > 644) aborting..." followed by "ERROR: receive_fd: EOF on 14". 100% repeatable on my system.
See attached logs for an example.
Running 3.1.2 on Centos 5.5 (x86 32 bit)
More information can be found at the following URL:
http://sip-router.org/tracker/index.php?do=details&task_id=121
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 user has added themself to the list of users assigned to this task.
FS#121 - Fault upon UA registration
User who did this - Mike Thomas (mthomasslo)
http://sip-router.org/tracker/index.php?do=details&task_id=121
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.
Module: sip-router
Branch: tma0/iptrtpproxy-v2
Commit: e8ced19c9b862fa4cd16f081625cbe8cb765d564
URL: http://git.sip-router.org/cgi-bin/gitweb.cgi/sip-router/?a=commit;h=e8ced19…
Author: Tomas Mandys <tomas.mandys(a)iptel.org>
Committer: Tomas Mandys <tomas.mandys(a)iptel.org>
Date: Tue Apr 5 21:47:01 2011 +0200
Log missed calls fix
Added flag to log also missed calls
---
etc/sip-router-oob.cfg | 22 ++++++++++++++--------
1 files changed, 14 insertions(+), 8 deletions(-)
diff --git a/etc/sip-router-oob.cfg b/etc/sip-router-oob.cfg
index f204ae8..3c7d694 100644
--- a/etc/sip-router-oob.cfg
+++ b/etc/sip-router-oob.cfg
@@ -358,7 +358,8 @@ flags
FLAG_RTP_PROXY : 13, # the RTP proxy is turned on
FLAG_NAT_REG : 14, # the UAC behind NAT, stored in location record
FLAG_INIT_DLG : 15, # init INVITE dialog
- FLAG_REVERSE_DIR : 16; # set if request goes callee -> caller direction, requires rr.append_fromtag=1
+ FLAG_REVERSE_DIR : 16, # set if request goes callee -> caller direction, requires rr.append_fromtag=1
+ FLAG_ACC_MISSED : 17; # the missed call will be recorded by ACC
avpflags
dialog_cookie; # attribute will be stored in Route headers
@@ -500,6 +501,8 @@ modparam("acc_db", "failed_transactions", 1)
# If you don't want to have accounting entries written into the database,
# comment the next line out.
modparam("acc_db", "log_flag", "FLAG_ACC")
+# seems "log_flag" and "log_flag_missed" cannot share the same flag!
+modparam("acc_db", "log_missed_flag", "FLAG_ACC_MISSED")
# if you would like to customize your CDRs, do it here....
#modparam("acc_db", "attrs",
@@ -724,24 +727,26 @@ route[INIT]
# Check if the UAC is NATed and fix the message accordingly
route(UAC_NAT_DETECTION);
- # if needed then we MUST put after force_rport() which is located in NAT_DETECTION!!!
- # Check t_reply() vs. sl_reply() usage in script
- #if (!t_newtran()) {
- # sl_reply("500", "Internal tm error");
- # drop;
- #}
-
# Activate accounting for all initial INVITEs. In-dialog requests
# are accounted by a RR cookie (see below).
# It should work also when the call has been already forked at a previous router
if (method == "INVITE" && !isflagset(FLAG_TOTAG)) {
$dialog_id = @sys.unique; # make unique dialogid
setflag(FLAG_ACC);
+ setflag(FLAG_ACC_MISSED);
setflag(FLAG_INIT_DLG);
} else if (isflagset(FLAG_TOTAG) && @hf_value.route[0].params.ftag != @from.tag) {
setflag(FLAG_REVERSE_DIR); # callee -> caller
}
+ # if needed then we MUST put after force_rport() which is located in NAT_DETECTION!!!
+ # also must be called after FLAG_ACC is set !!!
+ # Check t_reply() vs. sl_reply() usage in script
+ #if (!t_newtran()) {
+ # sl_reply("500", "Internal tm error");
+ # drop;
+ #}
+
# Set flag and use it instead of the attribute.
if ($replicate==1) {
setflag(FLAG_REPL_ENABLED);
@@ -946,6 +951,7 @@ route[PROCESS_ROUTES]
# for this.
if ($account == "yes") {
setflag(FLAG_ACC);
+ setflag(FLAG_ACC_MISSED);
}
# Restore the RTP proxy flag if present