sr-users December 2015

sr-users@lists.kamailio.org

70 participants
110 discussions

Kamailio on Mac
by Carlos Ruiz Díaz 04 Aug '16

04 Aug '16

Hi all, I'm switching my development environment from Linux to Mac. Is there any tutorial on how to setup Kamailio on this OS? It may be an Unix flavor, but it's still quite different from Linux :). Thanks, -- Carlos http://caruizdiaz.com http://ngvoice.com +52 55 3048 3303

6 9

t_on_branch_failure never called AND t_relay never fails in a, forked scenario
by Tristan Mahé 03 May '16

03 May '16

Hi fellow kamailio users, I'm playing actually with t_on_branch_failure, in a simultaneous forking scenario ( lookup("location") returns multiple contacts ). Any idea on how to get those "on_branch_failure" working ? Thanks in Advance ! * Test by putting failure_exec_mode: - at 1 => no branch failure being called, never. - at 0 => t_relay does not fail if a single branch answers the transaction, even if all other branches are failing. * Test by moving the t_on_branch_failure("manage_branch_failure"); line before or after the lookup("location") or on a _on_branch route to set it per branch. - The on_route branch are executed, but never the failure one. - tried also with failure_exec_mode = 0 or 1. * Using set_forward_no_connect, I can see in the logs a "Sending to branch X failed" but no failure route being executed. Without it, nothing in the logs indicating that the branch has timeout. * Config extract: # auto-discard branches from previous serial forking leg modparam("tm", "failure_reply_mode", 3) # 3 by default # default retransmission timeout: 30sec modparam("tm", "fr_timer", 30000) # default invite retransmission timeout after 1xx: 120sec modparam("tm", "fr_inv_timer", 120000) modparam("tm", "reparse_on_dns_failover", 0) # 1: Allow branches to have a per branch failure route # 0: t_relay should fail if a branch fail modparam("tm", "failure_exec_mode", 1) # Allow locally generated 408 to be forgotten in case a reply is received. #modparam("tm", "faked_reply_prio", 2000) # USER location service route[LOCATION] { t_on_branch_failure("manage_branch_failure"); if (!lookup("location")) { .... } # Let's get back after 2.5s if no 100/Trying received. t_set_fr(0, 2500); # set_forward_no_connect(); #t_on_branch("SET_BRANCH_FAILURE"); route(RELAY); exit; } route[RELAY] { .... if (!t_relay()) { xlog("L_WARN","$rm|$ci|$fu|$tu|RELAY_FAILED"); sl_reply_error(); } exit(); } # set failure route per branch branch_route[SET_BRANCH_FAILURE] { xlog("L_WARN","$rm|$ci|$fu|$tu|SETTING_BrANCH_FAILURE_ROUTE"); t_on_branch_failure("manage_branch_failure"); } # manage failure routing cases per branch event_route[tm:branch-failure:manage_branch_failure] { xlog("L_WARN","$rm|$ci|$fu|$tu[$avp(dest_to)]|MANAGE_BRANCH_FAILURE"); }

3 2

Record-Route header
by jignesh gandhi 01 Apr '16

01 Apr '16

Hello All, I have a need to save the Record-Route header from the INVITE and use it as a route header in requests like BYE. PROXY --> Kamailio(as PROXY) --> Asterisk I am using rr module to add a record_route when passing the INVITE to Asterisk. Thanks, Jignesh Gandhi

2 4

UDP send: Operation not permitted
by Sebastian Damm 11 Mar '16

11 Mar '16

Hi, we have a load balancer which is handling a lot of SIP traffic all day. There's always 20-40 Mbit SIP traffic going through. From time to time we see in our logs messages like these: Sep 16 09:46:28 ecker /usr/sbin/kamailio[25505]: ERROR: <core> [udp_server.c:591]: udp_send(): ERROR: udp_send: sendto(sock,0x7f2d9d6b3ce0,1321,0,46.237.225.126:5060,16): Operation not permitted(1) Sep 16 09:46:38 ecker /usr/sbin/kamailio[25194]: ERROR: <core> [udp_server.c:591]: udp_send(): ERROR: udp_send: sendto(sock,0x7efc982b8fc8,420,0,82.113.121.183:35794,16): Operation not permitted(1) Sep 16 09:46:40 ecker /usr/sbin/kamailio[25505]: ERROR: <core> [udp_server.c:591]: udp_send(): ERROR: udp_send: sendto(sock,0x7f2d9d6b3ce0,1338,0,5.158.137.9:55067,16): Operation not permitted(1) Sep 16 09:46:44 ecker /usr/sbin/kamailio[25183]: ERROR: <core> [udp_server.c:591]: udp_send(): ERROR: udp_send: sendto(sock,0x7efc982d9f48,450,0,178.165.131.197:37515,16): Operation not permitted(1) Sep 16 09:46:49 ecker /usr/sbin/kamailio[25643]: ERROR: <core> [udp_server.c:591]: udp_send(): ERROR: udp_send: sendto(sock,0x7f93fb624530,496,0,172.56.7.69:25643,16): Operation not permitted(1) Sep 16 09:46:55 ecker /usr/sbin/kamailio[25335]: ERROR: <core> [udp_server.c:591]: udp_send(): ERROR: udp_send: sendto(sock,0x7f41632cda98,598,0,80.215.234.139:3396,16): Operation not permitted(1) Sep 16 09:46:56 ecker /usr/sbin/kamailio[25345]: ERROR: <core> [udp_server.c:591]: udp_send(): ERROR: udp_send: sendto(sock,0x7f41632f4840,459,0,94.197.120.191:8225,16): Operation not permitted(1) I know that these messages can be produced by iptables blocking the outbound traffic. But our outbound chain looks basically like this: root@ecker:~# iptables-save | grep OUTPUT :OUTPUT DROP [0:0] -A OUTPUT -m state --state RELATED,ESTABLISHED -j ACCEPT -j ACCEPT -A OUTPUT -m state --state INVALID -j DROP -A OUTPUT -o lo -m state --state NEW -j ACCEPT -A OUTPUT -o lo -j ACCEPT -A OUTPUT -m state --state NEW -j ACCEPT We don't have the nf_ct_sip module loaded, syslog doesn't say anything, and even clearing all iptables rules doesn't eliminate those errors. Has anyone ever seen this? It looks like a load thing, because at weekends there are significantly less errors. Thanks, Sebastian

5 7

Kamailio TLS
by Kethzer Docteur 12 Feb '16

12 Feb '16

Im trying to enable Kamailio TLS but the configuration is not running at all when I cahnge it liike this as follow. Kamailio 3.3 ubuntu 12.04 LTS #!define WITH_TLS #!ifdef WITH_TLS enable_tls=yes #!endif #!ifdef WITH_TLS loadmodule "tls.so" #!endif #!ifdef WITH_TLS # ----- tls params ----- modparam("tls", "config", "/etc/kamailio/tls.cfg") #!endif Please help -- Kethzer Docteur

4 3

Kamailio 4.2.6 crash
by Igor Potjevlesch 11 Feb '16

11 Feb '16

Hello, I have seen couple of crashes since yesterday. I copy/paste the last "bt full": Program terminated with signal 11, Segmentation fault. #0 0x0000000000619694 in fm_extract_free (qm=0x7fcdf8780000, frag=0x7fcdf8a62c78) at mem/f_malloc.c:206 206 *pf= (gdb) bt full #0 0x0000000000619694 in fm_extract_free (qm=0x7fcdf8780000, frag=0x7fcdf8a62c78) at mem/f_malloc.c:206 pf = 0x6576203b50555349 hash = 2097 #1 0x000000000061ad68 in fm_malloc (qm=0x7fcdf8780000, size=1104, file=0x7fce0f081a7b "tm: t_msgbuilder.c", func=0x7fce0f0860a0 "build_local_reparse", line=369) at mem/f_malloc.c:490 f = 0x7fcdf8780b08 frag = 0x7fcdf8a62c78 hash = 156 __FUNCTION__ = "fm_malloc" #2 0x00007fce0f011fa9 in _shm_malloc (size=1099, file=0x7fce0f081a7b "tm: t_msgbuilder.c", function=0x7fce0f0860a0 "build_local_reparse", line=369) at ../../mem/shm_mem.h:208 p = 0x6 #3 0x00007fce0f01920e in build_local_reparse (Trans=0x7fcdf8a5e2f0, branch=0, len=0x7fff00c32fbc, method=0x7fce0f087a25 "ACK", method_len=3, to=0x7fff00c32d90, reason=0x0) at t_msgbuilder.c:369 invite_buf = 0x7fcdf8a62868 "INVITE sip:<CALLED>@goren SIP/2.0\r\nRecord-Route: <sip:A.B.C5.60;lr;did=5b1.3112>\r\nCSeq: 1 INVITE\r\nCall-ID: 3da8-469-1111201513435-JANGO-1-A.B.C_leg2\r\nFrom: <sip:<CALLING>@<HOST_FROM>>;"... invite_buf_end = 0x7fcdf8a62c70 "" cancel_buf = 0x415440 "1\355I\211\321^H\211\342H\203\344\360PTI\307\300\300\363m" s = 0x7fcdf8a62868 "INVITE sip:<CALLED>@goren SIP/2.0\r\nRecord-Route: <sip:A.B.C5.60;lr;did=5b1.3112>\r\nCSeq: 1 INVITE\r\nCall-ID: 3da8-469-1111201513435-JANGO-1-A.B.C_leg2\r\nFrom: <sip:<CALLING>@<HOST_FROM>>;"... s1 = 0x0 d = 0x10703ab0 <Address 0x10703ab0 out of bounds> invite_len = 1032 hf_type = 2540 first_via = 0 to_len = 67 cancel_buf_len = 1099 reason_len = 0 code_len = 0 reas1 = 0x0 reas_last = 0x0 hdr = 0xa7294e __FUNCTION__ = "build_local_reparse" #4 0x00007fce0f02e58b in build_ack (rpl=0x7fce107038b8, trans=0x7fcdf8a5e2f0, branch=0, ret_len=0x7fff00c32fbc) at t_reply.c:439 to = {s = 0xa728f6 "To: <sip:+<CALLED>@A.B.C5.60:5060>;tag=3658827875-928685\r\nContent-Length: 0\r\n\r\n", len = 67} __FUNCTION__ = "build_ack" #5 0x00007fce0f03b3ca in reply_received (p_msg=0x7fce107038b8) at t_reply.c:2253 msg_status = 488 last_uac_status = 100 ack = 0x7fce10588010 "\001" ack_len = 0 branch = 0 reply_status = 274235864 onreply_route = 1 cancel_data = {cancel_bitmap = 0, reason = {cause = 0, u = {text = {s = 0x0, len = 10955086}, e2e_cancel = 0x0, packed_hdrs = {s = 0x0, len = 10955086}}}} uac = 0x7fcdf8a5e458 t = 0x7fcdf8a5e2f0 lack_dst = {send_sock = 0x13a948, to = {s = {sa_family = 10306, sa_data = "\247\000\000\000\000\000(\r\030\000\000\000\000"}, sin = {sin_family = 10306, sin_port = 167, sin_addr = {s_addr = 0}, sin_zero = "(\r\030\000\000\000\000"}, sin6 = {sin6_family = 10306, sin6_port = 167, sin6_flowinfo = 0, sin6_addr = { __in6_u = {__u6_addr8 = "(\r\030\000\000\000\000\000\270|^\020\316\177\000", __u6_addr16 = {3368, 24, 0, 0, 31928, 4190, 32718, 0}, __u6_addr32 = {1576232, 0, 274627768, 32718}}}, sin6_scope_id = 93}}, id = 0, proto = -72 '\270', send_flags = {f = 106 'j', blst_imask = 94 '^'}} backup_user_from = 0x758a50 backup_user_to = 0x415440 backup_domain_from = 0x300c337e0 backup_domain_to = 0x0 backup_uri_from = 0x7fce10703ab0 backup_uri_to = 0x7fff00c330d0 backup_xavps = 0x628478 replies_locked = 0 branch_ret = 0 prev_branch = 275790040 blst_503_timeout = 32718 hf = 0x18e00c33060 onsend_params = {req = 0x7fff00c32f50, rpl = 0x47deb8, param = 0x0, code = 274623280, flags = 32718, branch = 0, t_rbuf = 0xa7294e, dst = 0xa727e1, send_buf = { s = 0x7fff00c33010 "\320\060", <incomplete sequence \303>, len = 6402299}} ctx = {rec_lev = 7715456, run_flags = 0, last_retcode = 7704068, jmp_env = {{__jmpbuf = {232, 140523014225936, 140523014226728, 140523014618240, 29, 0, 140523015781040, 4281408}, __mask_was_saved = 12793824, __saved_mask = {__val = {0, 140733206179856, 6439748, 140733206179616, 140523001001690, 140733206179584, 0, 67108864, 65537912, 1288288, 1570952, 1576232, 8, 94, 0, 1473240891392}}}}} __FUNCTION__ = "reply_received" #6 0x000000000048cc3a in do_forward_reply (msg=0x7fce107038b8, mode=0) at forward.c:783 new_buf = 0x0 dst = {send_sock = 0x0, to = {s = {sa_family = 0, sa_data = '\000' <repeats 13 times>}, sin = {sin_family = 0, sin_port = 0, sin_addr = {s_addr = 0}, sin_zero = "\000\000\000\000\000\000\000"}, sin6 = {sin6_family = 0, sin6_port = 0, sin6_flowinfo = 0, sin6_addr = {__in6_u = { __u6_addr8 = '\000' <repeats 15 times>, __u6_addr16 = {0, 0, 0, 0, 0, 0, 0, 0}, __u6_addr32 = {0, 0, 0, 0}}}, sin6_scope_id = 0}}, id = 0, proto = 0 '\000', send_flags = {f = 0 '\000', blst_imask = 0 '\000'}} new_len = 1 r = 0 ip = {af = 12792240, len = 32767, u = {addrl = {6466393, 280}, addr32 = {6466393, 0, 280, 0}, addr16 = {43865, 98, 0, 0, 280, 0, 0, 0}, addr = "Y\253b\000\000\000\000\000\030\001\000\000\000\000\000"}} s = 0x410004 "" len = 0 __FUNCTION__ = "do_forward_reply" #7 0x000000000048e27d in forward_reply (msg=0x7fce107038b8) at forward.c:885 ---Type <return> to continue, or q <return> to quit--- No locals. #8 0x0000000000509c9c in receive_msg ( buf=0xa727c0 "SIP/2.0 488 Not Acceptable Here\r\nVia: SIP/2.0/UDP A.B.C5.60;rport=5060;branch=z9hG4bKce12.98a05ce27e0243c4d775920d81e7ce82.0\r \nVia: SIP/2.0/UDP <HOST_FROM>;branch=z9hG4bK.5667f6e0\r\nFrom: <sip:332"..., len=398, rcv_info=0x7fff00c333b0) at receive.c:275 msg = 0x7fce107038b8 ctx = {rec_lev = 10237056, run_flags = 0, last_retcode = 0, jmp_env = {{__jmpbuf = {0, 0, 0, 272136986608, 1812476198913, 0, 272145363728, 272145384176}, __mask_was_saved = 0, __saved_mask = {__val = {140523014366192, 140733206180688, 1, 140522613671152, 272137013029, 50195, 1024, 4307759872, 140522613671152, 140733206180608, 6299381, 140733206180896, 140522613671152, 81, 6299509, 140733206180976}}}}} ret = 12792656 inb = { s = 0xa727c0 "SIP/2.0 488 Not Acceptable Here\r\nVia: SIP/2.0/UDP A.B.C5.60;rport=5060;branch=z9hG4bKce12.98a05ce27e0243c4d775920d81e7ce82.0\r \nVia: SIP/2.0/UDP <HOST_FROM>;branch=z9hG4bK.5667f6e0\r\nFrom: <sip:332"..., len = 398} __FUNCTION__ = "receive_msg" #9 0x0000000000608f02 in udp_rcv_loop () at udp_server.c:521 len = 398 buf = "SIP/2.0 488 Not Acceptable Here\r\nVia: SIP/2.0/UDP A.B.C5.60;rport=5060;branch=z9hG4bKce12.98a05ce27e0243c4d775920d81e7ce82.0\r \nVia: SIP/2.0/UDP <HOST_FROM>;branch=z9hG4bK.5667f6e0\r\nFrom: <sip:332"... tmp = 0x3f60c4067a <Address 0x3f60c4067a out of bounds> from = 0x7fce105e7920 fromlen = 16 ri = {src_ip = {af = 2, len = 4, u = {addrl = {151524537, 0}, addr32 = {151524537, 0, 0, 0}, addr16 = {5305, 2312, 0, 0, 0, 0, 0, 0}, addr = "\271\024\b\t", '\000' <repeats 11 times>}}, dst_ip = {af = 2, len = 4, u = {addrl = {1016190299, 0}, addr32 = {1016190299, 0, 0, 0}, addr16 = {54619, 15505, 0, 0, 0, 0, 0, 0}, addr = "[Õ<", '\000' <repeats 11 times>}}, src_port = 5060, dst_port = 5060, proto_reserved1 = 0, proto_reserved2 = 0, src_su = { s = {sa_family = 2, sa_data = "\023Ä¹\024\b\t\000\000\000\000\000\000\000"}, sin = {sin_family = 2, sin_port = 50195, sin_addr = {s_addr = 151524537}, sin_zero = "\000\000\000\000\000\000\000"}, sin6 = {sin6_family = 2, sin6_port = 50195, sin6_flowinfo = 151524537, sin6_addr = {__in6_u = { __u6_addr8 = '\000' <repeats 15 times>, __u6_addr16 = {0, 0, 0, 0, 0, 0, 0, 0}, __u6_addr32 = {0, 0, 0, 0}}}, sin6_scope_id = 0}}, bind_address = 0x7fce105aa2b0, proto = 1 '\001'} __FUNCTION__ = "udp_rcv_loop" #10 0x00000000004a6d9b in main_loop () at main.c:1629 i = 0 pid = 0 si = 0x7fce105aa2b0 si_desc = "udp receiver child=0 sock=A.B.C5.60:5060\000\177\000\000 5\303\000\377\177\000\000\003zN\000\000\000\000\000\016\b\000\000\377\177\00 0\000\260\204x\370\315\177\000\000\000\000\000\020\004\000\000\000\260\204x\ 370\315\177\000\000@TA\000\000\000\000\000\340\067\303\000\001\000\000\000p5 \303\000\377\177\000\000\246zN\000\000\000\000" nrprocs = 8 __FUNCTION__ = "main_loop" #11 0x00000000004acedf in main (argc=7, argv=0x7fff00c337e8) at main.c:2581 cfg_stream = 0xac7010 c = -1 r = 0 tmp = 0x7fff00c34f70 "" tmp_len = 32767 port = 12793534 proto = 0 options = 0x6ff8f8 ":f:cm:M:dVIhEeb:l:L:n:vKrRDTN:W:w:t:u:g:P:G:SQ:O:a:A:" ret = -1 seed = 3913881212 rfd = 4 debug_save = 0 debug_flag = 0 dont_fork_cnt = 0 n_lst = 0x40d11c p = 0xc2 <Address 0xc2 out of bounds> __FUNCTION__ = "main" Regards, Igor.

2 15

why msg_apply_changes() from REQUEST_ROUTE only
by smititelu 05 Feb '16

05 Feb '16

Hello, I don't understand why msg_apply changes() can be called from REQUEST_ROUTE *only*. Can someone explain? Can this be extended to *FAILURE_ROUTES *also? Basically I need to call this from FAILURE_ROUTES in order to avoid double SDP for rtpengine offers. Searching in the mailing list I could see that there could be other means of handling this like keeping and reading the SDP from an avp(write/read_sdp_pv), but I find the above method pretty straightforward. Thanks, Stefan

3 4

Kamailio and NAT
by Nelson Migliaro 15 Jan '16

15 Jan '16

Hello, I am running Kamailio behind NAT. Kanailio has a private IP and I am relaying NAT to internet router. I am using: - #!define WITH_NAT - listen=udp:PRIVATE-IP:5060 advertise PUBLIC-IP:5060 - Patched RTP proxy including the advertise option And everything goes fine. I can make calls and have two way audio. The problem begins when the callee ends the call. BYE is not received in Kamailio (caller) I included the public IP using "add_contact_alias" because "set_contact_alias" was not adding the public IP. I included this in in NATDETECT (pre loaded router) if(is_first_hop()) { xlog("L_NOTICE","Metodo: $rm \n"); xlog("L_NOTICE","is first hop\n"); #set_contact_alias(); if (!add_contact_alias("PUBLIC-IP", "$Rp", "udp")) { xlog("L_ERR", "Error in aliasing contact $ct\n"); send_reply("400", "Bad request"); exit; } } I think the problem is related to destination that BYE is sent by the vendor. From what I see IP and port is taken from advertised in contact (PUBLIC-IP and 5060). The problem is that internet router changes the source port. Contact: <sip:999999999@PRIVATE-IP:5060;alias=PUBLIC-IP~5060~1> --- Is it correcto to add_contact_alias("PUBLIC-IP", "$Rp", "udp") in order to received new transactions or should I follow a different procedure??? Thank you

4 14

Panning next major release - v4.4
by Daniel-Constantin Mierla 11 Jan '16

11 Jan '16

Hello, sketching the road to the next major release, so people can plan their goals for it and discuss, if needed, before the start of winter holidays: - development freezing by end of January 2016 - test for one to one and a half month - release in the first part of March 2016 If there are important topics to decide on, we can organize an IRC meeting sometime in January 2016. Cheers, Daniel -- Daniel-Constantin Mierla http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda Book: SIP Routing With Kamailio - http://www.asipto.com http://miconda.eu

4 10

Example kamailio.cfg t_check_trans()
by Phil Lavin 08 Jan '16

08 Jan '16

Hi there, The example config that Kamailio ships with contains this block of code in request_route: # handle retransmissions if(t_precheck_trans()) { t_check_trans(); exit; } t_check_trans(); I am not fully understanding the requirement for either of the t_check_trans() here. As far as I can see from the documentation, t_check_trans() returns a boolean value and does not modify any data internally. Can anyone help me find out what the relevance of the t_check_trans() calls is? Thanks Phil Lavin Systems Engineer CloudCall by SYNETY www.cloudcall.com<http://www.cloudcall.com> T: +44 (0) 330 335 0000 / +1 617 982 1600 D: +44 (0) 116 424 4790 / +1 617 982 4790 SM: LinkedIn<https://uk.linkedin.com/pub/phil-lavin/25/422/750> READ OUR BLOG FOR SMARTER COMMUNICATIONS<http://t.sidekickopen03.com/e1t/c/5/f18dQhb0S7lC8dDMPbW2n0x6l2B9nMJW7t5XX43…> Confidentiality: This e-mail transmission, including any attachments, is intended only for the named recipient(s) and may contain information that is privileged, confidential and/or exempt from disclosure under applicable law. If you have received this transmission in error, or are not the named recipient(s), please notify the sender immediately by return e-mail and permanently delete this transmission, including any attachments. Security: This e-mail and any attachments are believed to be free from any virus but it is the responsibility of the recipient to ensure this is so. E-mail is not a 100% secure communication.

2 3

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 December 2015