sr-users

sr-users@lists.kamailio.org

36 participants
37510 discussions

t_set_fr behaviour
by Kelvin Chua 06 Dec '17

06 Dec '17

hi guys, has anyone of you tried playing around with a scenario similar to this? A. invite -> t_set_fr() 2 seconds - if "100 trying" not received in 2 seconds, timeout. works fine. B. after receiving "100 trying" received, t_set_fr() 30 seconds - if 18x not received in 30 seconds, timeout. works fine C. after receiving the first 180, t_set_fr() 10 seconds - if "200 ok" not received in 10 seconds, it will not timeout, but instead it will timeout 30 seconds after B. i noticed this behavior recently and noticed that when a previous t_set_fr() is bigger than the new one, it will be ignored. so if i did 2 -> 10 -> 30, it works (swapping timeout values of B and C) my question is, is this an expected behavior? Kelvin Chua

2 2

load testing ims_charging
by Kelvin Chua 06 Dec '17

06 Dec '17

i am trying to load test the ims_charging module and notice some issues whenever i send test calls one by one, it's perfect. but when i use sipp and generate a bunch of calls, i would get this intermittently CRITICAL: ims_charging [ro_timer.c:122]: insert_ro_timer(): Trying to insert a bogus ro tl=0x7f207e91c2d0 tl->next=0x7f207e8b57b8 tl->prev=0x7f207e97c398 if i continue to hammer the server, it would end up failing all calls. When this issue happens, Ro_CCR will not return any value and will also not trigger the async route, looks like it just sits there frozen. during this time, sip client will receive a 408. also notice cdp complaining of latency usually around 1 second, using packet capture i am sure diameter server is responding properly. i think there is a choke point somewhere. i tried playing around with async_workers, no improvement. any pointers? Kelvin Chua

1 0

Re: [SR-Users] Kamailio Multi IP
by Duarte Rocha 06 Dec '17

06 Dec '17

Thnaks for the reply. I don't need mhomed since i do the socket forcing by myself after the the DISPATCH selects the Gateway. What i need is something that modifies the SIP Request in order to use the outbound IP in the R-URI, To-Header, etc. I'm doing that using the $td and $rd pseudo-variables, but i'm not sure if that is the safest approach. The TOPOS module is really usefull for this, thanks for mentioning. However, the dialog_expires parameter is really confusing, since it imposes a maximum time allowed for a dialog to exist (After the records are deleted, routing no longer works). I could work with a very long timer for this if the ended dialogs would get removed from the table automatically, but that doesn't happen. Cheers

1 0

redis via haproxy
by Aidar Kamalov 06 Dec '17

06 Dec '17

Hello, Kamailio after restart(or start) sometimes can't connect to redis (via haproxy) with logs: Dec 6 07:29:30 siptest /usr/sbin/kamailio[47291]: NOTICE: <script>: ROOT: KDMQ usrloc [764c076919c73540-39925(a)192.168.150.225] Dec 6 07:29:31 siptest /usr/sbin/kamailio[47263]: NOTICE: <script>: ROOT: OPTIONS <null> [0b4dc11225a6fc77294de97578061844@192.168.150.231:5060] Dec 6 07:29:31 siptest /usr/sbin/kamailio[47269]: ERROR: ndb_redis [redis_client.c:130]: redisc_init(): error communicating with redis server [redis] (127.0.0.1:6380/0): Resource temporarily unavailable Dec 6 07:29:31 siptest /usr/sbin/kamailio[47269]: ERROR: ndb_redis [ndb_redis_mod.c:122]: child_init(): failed to initialize redis connections Dec 6 07:29:31 siptest /usr/sbin/kamailio[47269]: ERROR: <core> [core/sr_module.c:923]: init_mod_child(): Error while initializing module ndb_redis (/usr/lib64/kamailio/modules/ndb_redis.so) Dec 6 07:29:31 siptest /usr/sbin/kamailio[47269]: ERROR: <core> [core/pt.c:334]: fork_process(): init_child failed for process 5, pid 47269, "udp receiver child=4 sock=192.168.8.213:5060" Dec 6 07:29:31 siptest /usr/sbin/kamailio[47269]: CRITICAL: <core> [main.c:1611]: main_loop(): Cannot fork Dec 6 07:29:31 siptest /usr/sbin/kamailio[47252]: ALERT: <core> [main.c:740]: handle_sigs(): child process 47269 exited normally, status=255 Dec 6 07:29:31 siptest /usr/sbin/kamailio[47362]: CRITICAL: <core> [core/pass_fd.c:277]: receive_fd(): EOF on 13 Redis and haproxy working fine (I test it by many attepts - echo ping|ncat localhost 6380) At tcpdump all attemps from kamailio have: *1 $4 PING +PONG *2 $6 SELECT $1 0 +OK my kamailio 5.0.4 config: modparam("ndb_redis", "server", "name=redis;addr=127.0.0.1;port=6380") my haproxy 1.5 config: backend bk_redis mode tcp option tcp-check tcp-check connect tcp-check send PING\r\n tcp-check expect string +PONG tcp-check send QUIT\r\n tcp-check expect string +OK server sipkazan 192.168.107.195:6379 check inter 1s server local 127.0.0.1:6379 check inter 1s backup -- Aydar A. Kamalov

2 2

Re: [SR-Users] using bcrypt passwd hashing
by Walter Martín Villalba 06 Dec '17

06 Dec '17

Hello everyone, and thanks very much for your feedback. Some responses and further questions below. Daniel> Latest kamailio versions support also SHA256 algorithm Martín> SHA256 is also a bad choice for storing passwords. See details here: https://crackstation.net/hashing-security.htm Daniel> However, the main blocker in suing a different hashing algorithm are the sip client devices (mainly hardphones), which implement only MD5. If you implement your own client app, then you can extend kamailio to support whatever hashing you do in the client. Then, of course you can use client side tls certificates for authentication, which should be better than any hashing algorithm. Martín> I do implement my own client app, even though I use a third party SIP stack, which currently doesn't support any other auth methods besides basic and MD5 (standard ones). I am planning to send username and passwd as custom SIP headers in the REGISTER message, probably encrypted, and this will travel on top of TLS. Then Kamailio can extract these custom headers and call a custom python script to decrypt the values and do the authentication (bcrypt password and compare with the one in database). Client certificates are good but only in certain situations (e.g. not if you want a zero footprint client such as a web-based client), and in most cases a pain to manage when your user base grows. Alex> Do you know of any mainstream SIP UACs which support anything other than standard MD5 digest auth? Martín> I don't, but haven't really worked much at all with 3rd party SIP clients. I doubt there's any support for newer passwd hashing schemes, unfortunately. ---------- Now the details.... I'm looking at sipcomm.cfg and see it calls www_authenticate (defined in modules/auth_db/authorize.c). I believe I would need to create a similar function, e.g. bcrypt_authenticate, and call this instead, with the username and passwd values I get in my custom headers (as explained above). The routine would decrypt the values, look up the user in the database, bcrypt the passwd extracted from the custom header, and compare with the one in the database. Doesn't sound too hard, but I do have some concerns related to other functions that www_authenticate may be doing, that I would also need to do in my bcrypt_authenticate function in order to keep Kamailio functioning properly. For example, www_authenticate could be changing some values in the database and/or other temporary storage. I took a quick look at the implementation and tried to follow the calls inside it. I see calls to mark_authorized_cred, check_auth_hr (or auth_check_hdr_md5), and generate_avps, and that some of these functions are indeed changing some values here and there. So, before spending more time looking into these details, I wanted to see if any of you have any suggestions about how to handle this situation, i.e. maybe all I need to do in bcrypt_authenticate is to check the credentials and then set one flag in the database for the user that was just authenticated? Does the explanation above make sense to you? Please let me know any suggestions or further guidance you may have. Thanks a lot, Martín. On Mon, Nov 13, 2017 at 3:00 AM, <sr-users-request(a)lists.kamailio.org> wrote: > Send sr-users mailing list submissions to > sr-users(a)lists.kamailio.org > > To subscribe or unsubscribe via the World Wide Web, visit > https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users > or, via email, send a message with subject or body 'help' to > sr-users-request(a)lists.kamailio.org > > You can reach the person managing the list at > sr-users-owner(a)lists.kamailio.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of sr-users digest..." > > > Today's Topics: > > 1. Branch 5.1 created (Daniel-Constantin Mierla) > 2. Development open in master branch (to be v5.2.x) > (Daniel-Constantin Mierla) > 3. Re: using bcrypt passwd hashing (Daniel-Constantin Mierla) > 4. Re: t_set_fr behaviour (Daniel-Constantin Mierla) > 5. Re: t_set_fr behaviour (Daniel-Constantin Mierla) > 6. Re: AVPOPS: is_avp_set/avp_check "name" parameter as > variable. (Daniel-Constantin Mierla) > 7. Re: strange --dialog in delete state is too old-- log line > managing dialog hashes (Daniel-Constantin Mierla) > 8. Re: 183 acc records even if early_media equals to 0 > (Marco Capetta) > 9. Re: Kamailio issue (Daniel-Constantin Mierla) > 10. Re: using bcrypt passwd hashing (Yuriy Gorlichenko) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Sun, 12 Nov 2017 14:42:35 +0100 > From: Daniel-Constantin Mierla <miconda(a)gmail.com> > To: "Kamailio (SER) - Devel Mailing List" <sr-dev(a)lists.kamailio.org>, > "Kamailio (SER) - Users Mailing List" <sr-users(a)lists.kamailio.org > > > Subject: [SR-Users] Branch 5.1 created > Message-ID: <dca81faa-dec2-4e12-704f-b382d23493d7(a)gmail.com> > Content-Type: text/plain; charset=utf-8 > > Hello, > > the GIT branch 5.1 has just been created, it will host the release > series 5.1.x. To get this branch from GIT, you can use: > > > git clone https://github.com/kamailio/kamailio.git kamailio > cd kamailio > git checkout -b 5.1 origin/5.1 > > > Hopefully in two-three weeks time frame the full release of 5.1.0 will > be out. > > >From now on, any corresponding fix has to be pushed first to master > branch and then cherry-picked to branch 5.1. No new features can get in > branch 5.1. Enhancements to documentation or helping tools, as well as > kemi exports are still allowed. If you are not sure about doing or not a > backport, ask on sr-dev mailing list. > > Cheers, > Daniel > > > -- > Daniel-Constantin Mierla > www.twitter.com/miconda -- www.linkedin.com/in/miconda > Kamailio Advanced Training - www.asipto.com > Kamailio World Conference - www.kamailioworld.com > > > > ------------------------------ > > Message: 2 > Date: Sun, 12 Nov 2017 14:50:45 +0100 > From: Daniel-Constantin Mierla <miconda(a)gmail.com> > To: "Kamailio (SER) - Devel Mailing List" <sr-dev(a)lists.kamailio.org>, > "Kamailio (SER) - Users Mailing List" <sr-users(a)lists.kamailio.org > > > Subject: [SR-Users] Development open in master branch (to be v5.2.x) > Message-ID: <07baf03f-0d1b-30f6-45d2-cacfc3dfec99(a)gmail.com> > Content-Type: text/plain; charset=utf-8 > > Hello, > > git branch 5.1 was just created (to host the release series v5.1.x), > therefore new features can now be pushed again in master branch. They > will be part of the next future release, likely to be numbered 5.2.x. > > Any fixes that affect existing code in branches 5.1 or older version > have to be backported - push first to master and then cherry pick -- see > the contributing guidelines at: > > - > https://www.kamailio.org/wiki/devel/git-commit-guidelines# > backporting_commits > > Many thanks to all contributors so far! Testing of branch 5.1 and giving > feedback for it is very appreciated! > > Cheers, > Daniel > > -- > Daniel-Constantin Mierla > www.twitter.com/miconda -- www.linkedin.com/in/miconda > Kamailio Advanced Training - www.asipto.com > Kamailio World Conference - www.kamailioworld.com > > > > > ------------------------------ > > Message: 3 > Date: Mon, 13 Nov 2017 09:22:17 +0100 > From: Daniel-Constantin Mierla <miconda(a)gmail.com> > To: "Kamailio (SER) - Users Mailing List" > <sr-users(a)lists.kamailio.org>, Yuriy Gorlichenko < > ovoshlook(a)gmail.com> > Subject: Re: [SR-Users] using bcrypt passwd hashing > Message-ID: <c7bb57e5-16dd-f5c2-f4ac-e3060f3b45bb(a)gmail.com> > Content-Type: text/plain; charset="utf-8" > > > > On 12.11.17 10:33, Yuriy Gorlichenko wrote: > > You can realize any of auth methods by yourself and include it via > > config file/kemi on lua/by adding module > > > > forexample I added SSO auth without any troubles instead of basid MD5 > > for some projects. > Out of curiosity, what do you refer by SSO? > > Cheers, > Daniel > > > > 2017-11-11 18:49 GMT+03:00 Alex Balashov <abalashov(a)evaristesys.com > > <mailto:abalashov@evaristesys.com>>: > > > > Do you know of any mainstream SIP UACs which support anything > > other than standard MD5 digest auth? > > > > On November 10, 2017 7:11:26 PM EST, "Walter Martín Villalba" > > <wvillalba(a)gmail.com <mailto:wvillalba@gmail.com>> wrote: > > >Hello, > > > > > >I did some searches online and talked to some colleagues and it > seems > > >Kamailio only supports the traditional HTTP digest authentication, > > >which > > >uses MD5. I would like to know if any of you has been successful in > > >using > > >bcrypt/scrypt/pbkdf2 passwd hashing, instead of MD5, which has been > > >deemed > > >as obsolete and insecure a long time ago. Perhaps you've written > your > > >own > > >auth module, or just modified the config script to call some other > > >credential checking routine using a custom python/perl script (I'm > > >thinking > > >of doing the latter, of nothing better is available). > > > > > >If any of you have done something like this, using bcrypt or any > > other > > >current and secure hashing algorithm, I would appreciate some > > guidance. > > > If > > >you haven't, aren't you concerned about storing MD5 password > > hashes in > > >your > > >database? > > > > > >Note: if I can't find a good answer using this list, I will try the > > >developer's list next. > > > > > >Thanks in advance, > > > > > >Martín. > > > > > > -- Alex > > > > -- > > Sent via mobile, please forgive typos and brevity. > > > > _______________________________________________ > > Kamailio (SER) - Users Mailing List > > sr-users(a)lists.kamailio.org <mailto:sr-users@lists.kamailio.org> > > https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users > > <https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users> > > > > > > > > > > _______________________________________________ > > Kamailio (SER) - Users Mailing List > > sr-users(a)lists.kamailio.org > > https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users > > -- > Daniel-Constantin Mierla > www.twitter.com/miconda -- www.linkedin.com/in/miconda > Kamailio Advanced Training, Nov 13-15, 2017, in Berlin - www.asipto.com > Kamailio World Conference - www.kamailioworld.com > >

1 0

Kamailio Multi IP
by Duarte Rocha 05 Dec '17

05 Dec '17

Greetings, I have a Kamailio that is hosted on multiple IP's. Each client connects to an IP and there is another IP that communicates with the PSTN. The problem is that I don't want any client "seeing" any IP besides his. If the client (connected to kamailio's IP 1.1.1.1) receives an request coming from the PSTN (connected to Kamailio's IP 2.2.2.2) , it will have 2.2.2.2 on the R-URI, To Header,etc. Is there a method to ensure kamailio will manipulate the packet and use the correct IP ? Currently i'm directly changing the R-URI and To Header, but I don't if it's the correct approach to this. I would also like to know the best way to do those changes right before the packet leaves Kamailio. I know that OnSend route doesn't allow changes in the buffer. I tried Branch routes but not every request goes through that. Thanks for the help. Cheers.

2 1

how to escape asterisk in pattern matching
by voipspace voipspace 05 Dec '17

05 Dec '17

how to escape asterisk in pattern matching if($rU=~"\d+*") regards

2 1

How to change To header URI from Kamailio?
by Arun NV 05 Dec '17

05 Dec '17

Hi, I am using *Kamailio 4.4*. I would like to forward the request to a different port number of my endpoint. I have changed the destination *URI *and the *INVITE *correctly reached to the new port. But the *To header *in the *INVITE *request has the old port. so the endpoint is not responding to the request. Then I tried to remove and replace *To header* using *remove_hf("To")* and* insert_hf("To: $var(modified_to_header) \r\n");* functions. But the to header not changed. So, is there any way to change the *To header URI*.

2 1

Dialog Module Hash Size vs Number of Dialogs
by Mark Blackford 04 Dec '17

04 Dec '17

Hello, I am trying to properly size the use of the Dialog Module hash for our implementation using: modparam("dialog", "hash_size", <number that is power of two>) However, in my testing, I have been unable to figure out the relationship between the hash size and a number of dialogs I need to support. I think the hash size is specifying a memory block in kB, but even setting the hash size to a very tiny number does stop me from creating hundreds of dialogs. Is there a way to determine a relationship between the hash size and a rough number of dialogs that would be expected? An example of a a dialog looks like this from kamctl: [root@kamailio01 ~]# kamctl dialog show dialog memory records dialog:: hash=22:70 state:: 4 ref_count:: 2 timestart:: 1512151205 timeout:: 36083666 callid:: 0gQAAC8WAAACBAAALxYAAClws2wyL8GE+CSgRY7HIhmg9ZUIISZad46ntOPng3iPIcLaxzLFaytRTI7M0Bzz0g--(a)10.155.8.40 from_uri:: sip:b53667d44239457fbc94fc2f4c4e25a6@sip.dcs-staging.net from_tag:: 10.155.8.40+1+689d7e5e+8fcf481a caller_contact:: sip:43f0ae1480846185e8803f21e9f2b721@10.155.8.40:5060 ;transport=udp caller_cseq:: 24115 caller_route_set:: caller_bind_addr:: udp:10.155.8.11:5060 callee_bind_addr:: udp:10.155.8.11:5060 to_uri:: sip:2052773090@sip.dcs-staging.net to_tag:: sip+1+bdcd0004+2038f37c callee_contact:: sip:ca2013e84f10348a1cc825c12562bde7@10.155.8.40:5060 ;transport=udp callee_cseq:: 0 callee_route_set:: Thanks! -- Mark Blackford Digium Cloud Services 678.230.8769

3 5

How to use ruri-pattern with allow_trusted?
by voipspace voipspace 04 Dec '17

04 Dec '17

Hi Have used allow_trused to pass the allowed ip. Now I want to check the request has a correct tech prefix. With an entry in ruri-patten column in the trusted table for example 75622#. So if calls are to olny be allowed when the "to" destination starts with 75622#. Regards

1 0

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

sr-users