sr-users

sr-users@lists.kamailio.org

37 participants
37511 discussions

Start a nNew thread

Registrar limit
by Yu Boot 09 Aug '17

09 Aug '17

How to limit one user login with one AOR (IP) and always use IP from last registration attempt?

2 1

RFC: Moving misc/obsolete/ to its own git repository
by Daniel-Constantin Mierla 09 Aug '17

09 Aug '17

Hello, trying to make the git repository a bit slimmer and avoid unuseful indexing of unused modules, I am considering to move misc/obsolete to its own github repository (planned to be named kamailio-obsolete). The initial idea was to keep there modules that were duplicated or no longer maintained, just in case someone will come later and wants to revive it. However, iirc, it is more than 4 years and nobody touched them, so very likely it requires a bit of work to revive any of them, so a fresh re-import will be the same from an external repository. If anyone still wants to keep them in the main kamailio repository, respond on the mailing list and present the benefits. If not, I will do the operation in the next several days. 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

1 1

"kamctl restart" fails
by Yu Boot 09 Aug '17

09 Aug '17

# kamctl restart INFO: Stopping Kamailio : INFO: stopped INFO: Starting Kamailio : 2292 pts/0 S+ 0:00 /bin/egrep kamailio -rw-r--r--. 1 kamailio kamailio 5 Aug 8 11:15 /var/run/kamailio.pid INFO: PID file exists (/var/run/kamailio.pid)! Kamailio already running? "service kamailio restart" works fine. What's wrong? Centos 6.9 x64, Kamailio 4.3 installed from official repo.

3 3

how to remove a line in sdp
by Sunil More 09 Aug '17

09 Aug '17

Hello All, I have the following SDP coming in from a carrier and would like to remove the following line. Cant figure how to go about it. line to remove : *a=cdsc: 1 image udptl t38* sdp is as below Content-Type: application/sdp. Content-Length: 293. . v=0. o=hiQ9200 5859020170708143552 1175715965 IN IP4 X.Y.Z.A. s=Phone Call via hiQ9200 SIPCA. c=IN IP4 X.Y.Z.A. t=0 0. m=audio 16648 RTP/AVP 8 101. a=rtpmap:8 PCMA/8000. a=rtpmap:101 telephone-event/8000. a=fmtp:101 0-15. a=sqn: 0. *a=cdsc: 1 image udptl t38.* a=sendrecv. a=ptime:20. This reply comes from a upstream carrier in session progress and 200ok causing one-way audio for me. Thanking You, Sunil More Ph : 9503338275

2 1

Billing plan
by Logeshwaran G 09 Aug '17

09 Aug '17

Hi, Is there any billing application or modules to use with kamailio , for example if i want to check the credits of the user on every passing minute , and when he's out of credits i stop the call. Thanks & Kind Regards, Logeshwaran G

2 1

sqlops error
by Logeshwaran G 09 Aug '17

09 Aug '17

modparam("sqlops","sqlcon",DBURL) Whether the above modparam implementation is wrong ? I am not sure Its saying some error as 0(2519) ERROR: sqlops [sql_api.c:669]: sql_parse_param(): invalid sqlops parameter

3 5

Core crash in del_lump() "offset exceeds message size" when using subst() inside tm:local-request route.
by Cody Herzog 08 Aug '17

08 Aug '17

Hello. Inside the tm:local-request route, I am trying to modify the body of outgoing NOTIFY messages using the subst_body() function. Things seem to work fine most of the time. The NOTIFY messages are correctly modified. However, I will very rarely hit a crash. I can force the crash to happen more quickly by stress testing with thousands of NOTIFY messages being modified. Is it safe to call subst() or subst_body() inside the tm:local-request route? If not, is there another way I can modify the outgoing NOTIFY messages safely? Note that I am also calling append_hf() inside the same tm:local-request route, but that has been working for a very long time without causing any problems. Could there be some kind of bad interaction between append_hf() and subst_body()? Strangely, it seems like using subst() makes the crash more likely to happen. For some reason, subst_body() seems to be more robust. Here are the logs I see: --------- Jul 28 10:57:40 SIPCOMM-VEGAS-TEST /usr/local/sbin/kamailio[2476]: CRITICAL: <core> [data_lump.c:292]: del_lump(): offset exceeds message size (1625 > 1194) aborting... Jul 28 10:57:43 SIPCOMM-VEGAS-TEST /usr/local/sbin/kamailio[2481]: CRITICAL: <core> [pass_fd.c:275]: receive_fd(): EOF on 53 Jul 28 10:57:44 SIPCOMM-VEGAS-TEST /usr/local/sbin/kamailio[2367]: ALERT: <core> [main.c:731]: handle_sigs(): child process 2476 exited by a signal 6 Jul 28 10:57:44 SIPCOMM-VEGAS-TEST /usr/local/sbin/kamailio[2367]: ALERT: <core> [main.c:734]: handle_sigs(): core was generated Jul 28 10:57:44 SIPCOMM-VEGAS-TEST /usr/local/sbin/kamailio[2367]: INFO: <core> [main.c:756]: handle_sigs(): terminating due to SIGCHLD --------- Here is a GDB back trace from the core dump: --------- #0 0x00007fd91a567c37 in __GI_raise (sig=sig@entry=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:56 #1 0x00007fd91a56b028 in __GI_abort () at abort.c:89 #2 0x000000000044e981 in del_lump (msg=0x7fd917c5ed60 <lreq>, offset=1625, len=20, type=HDR_OTHER_T) at data_lump.c:293 #3 0x00007fd91676297f in subst_f (msg=0x7fd917c5ed60 <lreq>, subst=0x7fd919e5ccc0 "\320\356\345\031\331\177", ignored=0x0) at textops.c:681 #4 0x000000000041e1dd in do_action (h=0x7ffd364b87c0, a=0x7fd919e9b438, msg=0x7fd917c5ed60 <lreq>) at action.c:1059 #5 0x000000000042a917 in run_actions (h=0x7ffd364b87c0, a=0x7fd919e9b438, msg=0x7fd917c5ed60 <lreq>) at action.c:1548 #6 0x000000000042af94 in run_actions_safe (h=0x7ffd364ba5b0, a=0x7fd919e9b438, msg=0x7fd917c5ed60 <lreq>) at action.c:1613 #7 0x0000000000549972 in rval_get_int (h=0x7ffd364ba5b0, msg=0x7fd917c5ed60 <lreq>, i=0x7ffd364b8b58, rv=0x7fd919e9ced8, cache=0x0) at rvalue.c:912 #8 0x000000000054dc7c in rval_expr_eval_int (h=0x7ffd364ba5b0, msg=0x7fd917c5ed60 <lreq>, res=0x7ffd364b8b58, rve=0x7fd919e9ced0) at rvalue.c:1910 #9 0x000000000041dc52 in do_action (h=0x7ffd364ba5b0, a=0x7fd919e9d990, msg=0x7fd917c5ed60 <lreq>) at action.c:1029 #10 0x000000000042a917 in run_actions (h=0x7ffd364ba5b0, a=0x7fd919e9d990, msg=0x7fd917c5ed60 <lreq>) at action.c:1548 #11 0x000000000041e0c4 in do_action (h=0x7ffd364ba5b0, a=0x7fd919e9dad8, msg=0x7fd917c5ed60 <lreq>) at action.c:1044 #12 0x000000000042a917 in run_actions (h=0x7ffd364ba5b0, a=0x7fd919e973b8, msg=0x7fd917c5ed60 <lreq>) at action.c:1548 #13 0x000000000041ab46 in do_action (h=0x7ffd364ba5b0, a=0x7fd919e95d70, msg=0x7fd917c5ed60 <lreq>) at action.c:677 #14 0x000000000042a917 in run_actions (h=0x7ffd364ba5b0, a=0x7fd919e8f330, msg=0x7fd917c5ed60 <lreq>) at action.c:1548 #15 0x000000000041e0c4 in do_action (h=0x7ffd364ba5b0, a=0x7fd919e95eb8, msg=0x7fd917c5ed60 <lreq>) at action.c:1044 #16 0x000000000042a917 in run_actions (h=0x7ffd364ba5b0, a=0x7fd919e8c8e0, msg=0x7fd917c5ed60 <lreq>) at action.c:1548 #17 0x000000000042b07d in run_top_route (a=0x7fd919e8c8e0, msg=0x7fd917c5ed60 <lreq>, c=0x0) at action.c:1634 #18 0x00007fd917a0539a in t_uac_prepare (uac_r=0x7ffd364baf20, dst_req=0x7ffd364ba8f0, dst_cell=0x7ffd364ba8f8) at uac.c:391 #19 0x00007fd917a07945 in t_uac_with_ids (uac_r=0x7ffd364baf20, ret_index=0x0, ret_label=0x0) at uac.c:599 #20 0x00007fd917a07918 in t_uac (uac_r=0x7ffd364baf20) at uac.c:584 #21 0x00007fd917a09b9e in req_within (uac_r=0x7ffd364baf20) at uac.c:802 #22 0x00007fd914674052 in send_notify_request (subs=0x7ffd364bb200, watcher_subs=0x0, n_body=0x0, force_null_body=0) at notify.c:1600 #23 0x00007fd9146754b3 in notify (subs=0x7ffd364bb200, watcher_subs=0x0, n_body=0x0, force_null_body=0) at notify.c:1690 #24 0x00007fd9146cec6a in update_subscription (msg=0x7fd919efeb70, subs=0x7ffd364bb200, to_tag_gen=1, sent_reply=0x7ffd364bb16c) at subscribe.c:697 #25 0x00007fd9146d45b7 in handle_subscribe (msg=0x7fd919efeb70, watcher_user=..., watcher_domain=...) at subscribe.c:1057 #26 0x00007fd9146d08b0 in handle_subscribe0 (msg=0x7fd919efeb70) at subscribe.c:816 #27 0x000000000041e155 in do_action (h=0x7ffd364bd680, a=0x7fd919e19508, msg=0x7fd919efeb70) at action.c:1053 #28 0x000000000042a917 in run_actions (h=0x7ffd364bd680, a=0x7fd919e19508, msg=0x7fd919efeb70) at action.c:1548 #29 0x000000000041e112 in do_action (h=0x7ffd364bd680, a=0x7fd919e19650, msg=0x7fd919efeb70) at action.c:1048 #30 0x000000000042a917 in run_actions (h=0x7ffd364bd680, a=0x7fd919e02638, msg=0x7fd919efeb70) at action.c:1548 #31 0x000000000041e0c4 in do_action (h=0x7ffd364bd680, a=0x7fd919e199c0, msg=0x7fd919efeb70) at action.c:1044 #32 0x000000000042a917 in run_actions (h=0x7ffd364bd680, a=0x7fd919e199c0, msg=0x7fd919efeb70) at action.c:1548 #33 0x000000000041e112 in do_action (h=0x7ffd364bd680, a=0x7fd919e19b08, msg=0x7fd919efeb70) at action.c:1048 #34 0x000000000042a917 in run_actions (h=0x7ffd364bd680, a=0x7fd919df99d8, msg=0x7fd919efeb70) at action.c:1548 #35 0x000000000041ab46 in do_action (h=0x7ffd364bd680, a=0x7fd919dbe960, msg=0x7fd919efeb70) at action.c:677 #36 0x000000000042a917 in run_actions (h=0x7ffd364bd680, a=0x7fd919daedf8, msg=0x7fd919efeb70) at action.c:1548 #37 0x000000000042b07d in run_top_route (a=0x7fd919daedf8, msg=0x7fd919efeb70, c=0x0) at action.c:1634 #38 0x000000000050f678 in receive_msg (buf=0x7fd8f2c6ce28 "SUBSCRIBE sip:endpoint-1720@intouchstaging.com SIP/2.0\r\nRecord-Route: <sip:64.64.203.109:443;transport=tls;lr=on>\r\nAccept: application/dialog-info+xml, application/pidf+xml, application/pidf-diff+xml,"..., len=1284, rcv_info=0x7fd8f2c6cb50) at receive.c:196 #39 0x00000000005fb99e in receive_tcp_msg (tcpbuf=0x7fd8f2c6ce28 "SUBSCRIBE sip:endpoint-1720@intouchstaging.com SIP/2.0\r\nRecord-Route: <sip:64.64.203.109:443;transport=tls;lr=on>\r\nAccept: application/dialog-info+xml, application/pidf+xml, application/pidf-diff+xml,"..., len=1284, rcv_info=0x7fd8f2c6cb50, con=0x7fd8f2c6cb38) at tcp_read.c:1207 #40 0x00000000005fd48c in tcp_read_req (con=0x7fd8f2c6cb38, bytes_read=0x7ffd364bdb7c, read_flags=0x7ffd364bdb84) at tcp_read.c:1411 #41 0x0000000000600aee in handle_io (fm=0x7fd919f07d80, events=1, idx=-1) at tcp_read.c:1643 #42 0x00000000005f3ab8 in io_wait_loop_epoll (h=0xa3d3e0 <io_w>, t=2, repeat=0) at io_wait.h:1061 #43 0x0000000000601cf7 in tcp_receive_loop (unix_sock=57) at tcp_read.c:1755 #44 0x00000000005ea235 in tcp_init_children () at tcp_main.c:4788 #45 0x00000000004ab048 in main_loop () at main.c:1675 #46 0x00000000004b10c2 in main (argc=13, argv=0x7ffd364be258) at main.c:2566 --------- Thanks very much. -Cody

2 8

kamailio + dispatcher asterisks + pstn gateways
by Aidar Kamalov 08 Aug '17

08 Aug '17

Hello, Whats the best way to provide subject? Now I have central kamailio server and (asterisk "media" servers + asterisk pstn gateway in different cities). Kamailio default config with some changes in route[LOCATION] if (!lookup("location")) { $var(rc) = $rc; route(TOVOICEMAIL); t_newtran(); switch ($var(rc)) { case -1: xwarn("Contact $rU not registered. Forwarding call to dispatcher"); append_hf("X-External: true\r\n"); $rU = "00"+$rU; break; case -3: send_reply("404", "Not Found"); exit; case -2: send_reply("405", "Method Not Allowed"); exit; } } ...... # when routing via usrloc, log the missed calls also if (is_method("INVITE")) { setflag(FLT_ACCMISSED); } if(!ds_is_from_list()) { route(DISPATCH); } route(RELAY); So all calls going to asterisk server. Not local calls with 00 prefix. And asterisk context: context kamailio { _X. => { Noop(CALL to kamailio user ${EXTEN}); Dial(SIP/${EXTEN}@${SIPDOMAIN},60,RTt); Hangup; } _00X. => { Noop(CALL to external user ${EXTEN}); Dial(SIP/PSTN-SERVER/${EXTEN:2},60,RTt); Hangup; } } Is it right way? Maybe any better approach? How to keep route logic at kamailio, but use dispatcher asterisk to proccess the calls to pstn(all endpoints at one city to pstn asterisk at this city. In others city there are other pstn gateways)? -- Aydar A. Kamalov

1 0

How to simulate a group call with kamailio ?
by leslie mekiyess 08 Aug '17

08 Aug '17

Hi, I have installed the latest kamailio on linux integrated with MYSQL server, What are the procedures ( configuration / commands etc ...) to simulate a group call ? BR, Leslie.

1 0

carrierroute and failure route
by Yu Boot 08 Aug '17

08 Aug '17

Hello. I'm trying to make carrierroute work on default kamailio.cfg first route: FXS gw ->(NAT)->Kami->FS->PSTN second route FXS gw->(NAT)-> Kami->Mediant2000->E1->PSTN First one works OK, but if second route triggers, the following disaster occurs (tshark dump) https://pastebin.com/00Ayty36 carrierroute is used as following https://pastebin.com/5J1atq00 What's wrong?

5 12

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