Hello,
it is almost 2 months since we packaged 3.1.2, there are commits
accumulated in branch 3.1, therefore I plan to package 3.1.3 Monday or
Tuesday next week. If anyone has something to add in this regards,
please reply.
Cheers,
Daniel
--
Daniel-Constantin Mierla
http://www.asipto.com
Hello,
iirc this was at some point discussed, however, I want to go through it
again.
Many x86_64 distros expect libraries to be placed under a lib64
directory. For example the RPM spec file language returns /usr/lib64 for
%{_libdir} variable.
In the master branch I committed a patch that does this detection.
As I saw some people saying that 'lib' should be the default also for
x86_64, my question is then what do you think we should use?
Using 'lib' will definitely make building rpms fail unless we do a patch
specific for these distros.
Cheers,
Daniel
--
Daniel-Constantin Mierla
http://www.asipto.com
Hi all,
I'm running 3.1-branch git head currently under valgrind. And I've seen
several invalid reads and writes (apparently most are off by one).
==22274== Invalid read of size 1
==22274== at 0x6DA2C0A: pv_set_ruri_user (pv_core.c:1755)
==22274== by 0x13BA15: lval_pvar_assign (lvalue.c:357)
==22274== by 0x13BF0F: lval_assign (lvalue.c:405)
==22274== by 0x139E4D: do_action (action.c:1472)
==22274== by 0x13A6F1: run_actions (action.c:1555)
==22274== by 0x12FDEB: do_action (action.c:711)
==22274== by 0x13A6F1: run_actions (action.c:1555)
==22274== by 0x13A86F: run_actions_safe (action.c:1607)
==22274== by 0x1E2666: rval_get_int (rvalue.c:904)
==22274== by 0x1E5252: rval_expr_eval_int (rvalue.c:1866)
==22274== by 0x131B8A: do_action (action.c:1071)
==22274== by 0x13A6F1: run_actions (action.c:1555)
Is fairly obvious. modules_k/pv/pv_core.c has several places which take
backup of "val->rs.s[val->rs.len]" and replaces it with zero for string
termination. It's than later on set back to the original value. However,
it would appear that the value passed does not always point to a memory
area which is large enough. This results in multiple invalid reads and
writes of one.
The remaining reads are not so clear to me.
==22274== Invalid read of size 1
==22274== at 0x4811A69: strncpy (mc_replace_strmem.c:339)
==22274== by 0x6DA77FF: set_var_value (pv_svar.c:122)
==22274== by 0x6DA1EDB: pv_set_scriptvar (pv_core.c:1636)
==22274== by 0x13BA15: lval_pvar_assign (lvalue.c:357)
==22274== by 0x13BF0F: lval_assign (lvalue.c:405)
==22274== by 0x139E4D: do_action (action.c:1472)
==22274== by 0x13A6F1: run_actions (action.c:1555)
==22274== by 0x131E05: do_action (action.c:1086)
==22274== by 0x13A6F1: run_actions (action.c:1555)
==22274== by 0x12FDEB: do_action (action.c:711)
==22274== by 0x13A6F1: run_actions (action.c:1555)
==22274== by 0x131E05: do_action (action.c:1086)
==22274== Invalid read of size 2
==22274== at 0x4811E1F: memcpy (mc_replace_strmem.c:523)
==22274== by 0x1E134D: rval_new_str (rvalue.c:269)
==22274== by 0x1E394E: rval_convert (rvalue.c:1301)
==22274== by 0x1E4780: rval_str_add2 (rvalue.c:1610)
==22274== by 0x1E8681: rval_expr_eval (rvalue.c:2399)
==22274== by 0x13BBD9: lval_assign (lvalue.c:389)
==22274== by 0x139E4D: do_action (action.c:1472)
==22274== by 0x13A6F1: run_actions (action.c:1555)
==22274== by 0x12FDEB: do_action (action.c:711)
==22274== by 0x13A6F1: run_actions (action.c:1555)
==22274== by 0x139229: do_action (action.c:1342)
==22274== by 0x13A6F1: run_actions (action.c:1555)
Any ideas how to fix these? Or any instructions what to provide more in
the bug report?
Cheers,
Timo
Hello,
there is now a service on opensuse build server to create kamailio
v3.1.2 (git branch 3.1.2) RPMs i586/x86_63 for Centos 5.5, RedHat 5,
Fedora 14 and OpenSuse 11.4, you can check this project at:
https://build.opensuse.org/package/show?package=kamailio&project=home%3Akam…
Download links are:
http://download.opensuse.org/repositories/home:/kamailio:/telephony/CentOS_…http://download.opensuse.org/repositories/home:/kamailio:/telephony/RedHat_…http://download.opensuse.org/repositories/home:/kamailio:/telephony/Fedora_…http://download.opensuse.org/repositories/home:/kamailio:/telephony/openSUS…
The x86_64 build for opensuse is still not completed, some parameter to
gcc compiler is not working, should be fixed soon.
Note that not all modules are packaged since not all dependencies were
met in these distros.
The RPM spec was started from what is in source tree as
kamailio.spec.CentOS, radically updated for cross compilation.
Personally I am not using these distros, therefore it will be
appreciated if people using any of them are willing to give an
installation test and report if all goes ok.
Moreover, I will be very thankful if anyone (can be many) wants to jump
in and take over the maintenance of this kamailio build service. It
would be good to enable the build for other versions of these distros,
probably for many it will just work, if not it will require some
adjustments on dependencies. Once these builds prove to be ok and
useful, we can move them in the global telephony repository of the
opensuse build service.
Cheers,
Daniel
--
Daniel-Constantin Mierla
http://www.asipto.com
Hello.
Can someone please explain to me hoy can i use the command “defunct_gw()” is
used to mark a gw down?.
I understand that the gateway is marked down for period of time with the
command, but how can I check if a gateway is down?. Can someone show me
this with an example in the configuration?
*Thanks in advance,*
*Regards,*
* *
* *
*Ricardo Martinez.-*
Hi ,
Currently i am working with opensips and i am able to call throgh opensips and show the cdrs
but there is problem of accounting that how i can give the balance to the customer and how to
charge the rates for diffrent country.
There is the option call control for opensips and this is related to media proxy and radius server.
I am using centos OS for opensips .Please help me if any body know this options(call control).
Waiting for your response.
Thanks and Regards
Parikhita
For what it's worth, make sure you have the mhomed patch in forward.c. As I
recall, the 3.1.2 source
tarball did not contain the fix, but the latest forward.c did.
http://www.mail-archive.com/sr-users@lists.sip-router.org/msg03892.html
Sean O'Donnell
Senior Engineer
uReach Technologies, Inc.
---- On Wed, 30 Mar 2011, Bruce McAlister (bruce.mcalister(a)blueface.ie) wrote:
All,
Thanks for the tips and suggestions, I have now managed to get this
working using mhomed=1 and setting $fs, for some reason I could not get
"force_send_socket" to work with avp's (but thats a topic for another
thread).
Thanks again for your time.
_______________________________________________
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
Hi All,
I'm trying to setup an active/passive proxy instance with kamailio
3.1.2. I'm using ucarp (www.ucarp.org) to provide the floating ip
addresses. I have installed and configured ucarp and it appears to be
working as expected.
I have configured kamailio on both systems to be online all the time
(using the net.ipv4.ip_nonlocal_bind kernel parameter on the "standby"
server). I have configured kamailio with the listen parameter to be
listening on the floating ip addresses only.
The problem now is that kamailio uses the inbound interface as the
outbound socket for messages (I think this is the default, expected,
behaviour).
If I enable the "mhomed" parameter then I get the following error:
ERROR: <core> [forward.c:218]: ERROR: get_out_socket: no socket found
ERROR: <core> [forward.c:572]: forward_req: ERROR: cannot forward to af
2, proto 1 no corresponding listening socket ERROR: sl [sl_funcs.c:282]:
ERROR: sl_reply_error used: I'm terribly sorry, server error occurred (7/SL)
I had a look around on the docuwiki and I found $fs. Would I need to
force the outbound socket for each message in this case, or do I have a
simple comfiguration issue?
Any thoughts/comments would be greatly appreciated.
Thanks
HI
I did the trace using ngrep:
ngrep -T -W byline -d any port 5060
And I am confused with tm retran.
(1) case one
tm module, the| retr_timer1| default is 500 ms.
#U +0.001824 xxx.17:5060 -> xxx.16:5060
INVITE sip:224@172.16.8.49:2057;line=lnzlkxu5 SIP/2.0.
#U +0.000012 xxx.17:5060 -> xxx.16:5060
INVITE sip:224@172.16.8.49:2057;line=lnzlkxu5 SIP/2.0.
the ngrep show the delta between packet, the second invite is only 12
ms behind?
is my understanding correct?
(2) change retr_timer1 to 2000 ms
modparam("tm", "retr_timer1", 1000)
#U +0.001936 xxx.17:5060 -> xxx.16:5060
INVITE sip:224@172.16.8.49:2057;line=lnzlkxu5 SIP/2.0.
#U +0.000013 xxx.17:5060 -> xxx.16:5060
INVITE sip:224@172.16.8.49:2057;line=lnzlkxu5 SIP/2.0.
the delta still 13 ms behind, so similar to the case 1,
The question is: is the second invite the re-trans by tm?
If so why it is around 12/13 ms? not the 500 ms or as configured 2000 ms?
thanks.
Kind regards / Mit freundlichen Grüßen
Min Wang
Hello,
I thought it is an useful information to announce here that the SIP
Communicator SIP softphone was renamed to Jitsi. There are several pages
mentioning Kamailio and SIP Communicator out there, among them our
participation to Google Summer of Code 2010 as well as the full SIP
SIMPLE Presence configuration with XCAP:
* http://asipto.com/u/sp
To fetch the latest version of this sip softphone you just go to:
* http://www.jitsi.org
Btw, Kamailio is participating again in GSoC, the 2011 edition, together
with Jitsi project -- I will make another message regarding this subject.
Cheers,
Daniel
--
Daniel-Constantin Mierla
http://www.asipto.com
