sr-users September 2014

sr-users@lists.kamailio.org

96 participants
170 discussions

by marino.mileti＠alice.it

Hi, I'm having a problem with routing of BYEs in my multi homed Kamailio. My setup is a Kamailio v4.1.5 with two NIC (172.20.11.0 & 192.168.10.0) and three phones. Two phones (1 for each LAN) are in a group, so using alias_db I can call them in parallel mode. Caller is on 172.20 network...When I answer from phone on 192.168.10.0, RTP is ok ... but on BYE Kamailio replies with 404 Not Here...and the RURI of BYE has the IP of Kamailio instead the IP of the callee.When I answer from phone on 172.20.11.0, RTP is still ok and also BYE is managed correctly from Kamailio and the RURI of BYE has the IP of the callee. How can i solve this issue?Many thanks

10 years, 2 months

Re: [SR-Users] [OT] Accounting Drouting Gateway Selection

by Dan Christian Bogos

Hi Spencer, We use a similar approach as yours and use 302 Redirects coming from Kamailio instead of proxying the call (in our case we do it via LCR module in Kamailio). In FreeSWITCH you can then manually route these redirects and get your CDR data out of it. Cheers, DanB On 22.09.2014 12:00, sr-users-request(a)lists.sip-router.org wrote: > On 18/09/14 17:34, Spencer Thomason wrote: >> >Hello all, >> >I have a need to determine which calls go to which gateway. The challenge is that CDRs are produced by a FreeSWITCH instance upstream of a provider side Kamailio proxy that handles route selection via drouting module. The topology is like this: >> > >> >customer proxy -> FS [1-N] (accounting) -> carrier proxy (route selection) >> > >> >Does anyone have any ideas how to make the FreeSWITCH instances aware of which gateway actually received the call?

10 years, 2 months

Kamailio fronting Freeswitch authentication

by Ashwin Jain

Hi all, I am using Kamailio to front my freeswitch servers and it is working great. I am getting some problems with authentication, sometimes users which are not registered with kamailio are also able to make calls. I have a feeling that I am doing something really silly with kamailio routing. Following is the AUTH route that I am using, please let me know I am missing something very obvious. route[AUTH] { #!ifdef WITH_AUTH #!ifdef WITH_FREESWITCH if(route(FSINBOUND)) return; #!endif #!ifdef WITH_IPAUTH if((!is_method("REGISTER")) && allow_source_address()) { # source IP allowed return; } #!endif if (is_method("REGISTER") || from_uri==myself) { # authenticate requests if (!auth_check("$fd", "subscriber", "1")) { auth_challenge("$fd", "0"); exit; } # user authenticated - remove auth header if(!is_method("REGISTER|PUBLISH")) consume_credentials(); } # if caller is not local subscriber, then check if it calls # a local destination, otherwise deny, not an open relay here if (from_uri!=myself && uri!=myself) { sl_send_reply("403","Not relaying"); exit; } #!endif return; } route[FSINBOUND] { if($si== $sel(cfg_get.freeswitch.bindip) && $sp==$sel(cfg_get.freeswitch.bindport)) return 1; return -1; } I have set "WITH_AUTH" and "WITH_FREESWITCH". Let me know, if any more details are required. System configuration: Ubuntu: 12.04 LTS Kamailio: 4.1.5 (x86_64/linux) Freeswitch: 1.4.7 stable release -- Thanks and Regards, Ashwin Jain

10 years, 2 months

[OT] Accounting Drouting Gateway Selection

by Spencer Thomason

Hello all, I have a need to determine which calls go to which gateway. The challenge is that CDRs are produced by a FreeSWITCH instance upstream of a provider side Kamailio proxy that handles route selection via drouting module. The topology is like this: customer proxy -> FS [1-N] (accounting) -> carrier proxy (route selection) Does anyone have any ideas how to make the FreeSWITCH instances aware of which gateway actually received the call? Thanks! Spencer

10 years, 2 months

Fwd: Kamailio 4.0.2 as a new Port for FreeBSD

by Oliver Mahmoudi

Hello, The port has just been committed to the FreeBSD ports tree and has been mapped to: /usr/ports/net/kamailio It can be compiled and installed with FreeBSD's traditional: # make install clean It compiles on 8.x, 9.x and 10.x for the i386 and x86-64 architectures. Possibly for the others archs too, but they to my knowing haven't been thoroughly tested so far. We'll find out on the way. The way things look, I will be the ports defacto maintainer. After finishing my first draft of the port about a year ago, I ran a few tests between a Kamailio server on FreeBSD and a Windows host using MySQL as a phonebook and Jitsi as a frontend GUI. From the Kamailio point of view, things worked fine, however, the only problem was, that I wasn't really able to test voice functionality, since jitsi had some problems accessing soundcard features on FreeBSD. Maybe things have changed since then and/or this will give rise to new research in this area. In case you are interested and for your cross-reference, you can find the entire discussion that took place concerning the port here: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=181301 Moreover, to this e-mail attached, you will find a shell archive (kamailio.shar) of the port the way it has been mapped into the ports tree. Enjoy using Kamailio on FreeBSD! Oliver Mahmoudi On Tue, Jul 23, 2013 at 7:51 PM, Daniel-Constantin Mierla <miconda(a)gmail.com > wrote: > Hello, > > > On 7/23/13 1:31 AM, Oliver Mahmoudi wrote: > >> Hello, >> >> I am currently working on porting Kamailio 4.0.2 to the >> FreeBSD ports collection: /usr/ports, and I just have a >> few general questions regarding compilation with regard >> to the extra modules. >> >> There are 172 modules that come with Kamailio, and most, >> however not all of them are compiled by default: >> >> # gmake all >> >> The base server and the base modules compile fine on >> my 9.1 release. >> >> To really compile all of the 172 modules, Kamailio_4_0_2/INSTALL >> says that the following external libraries (LIB_DEPENDS I assume) >> are needed: >> >> /usr/ports/databases/mysql-client-* >> /usr/ports/databases/postgresql-libpqxx >> /usr/ports/textproc/expat2 >> /usr/ports/textproc/libxml2 >> /usr/ports/net/radiusclient >> >> This is put down as information for FreeBSD 5.4. Does that still hold >> current for 9.1? >> >> Is there an exhaustive list of all the modules that the all target >> does/does not compile and - apart from mysql, postgresql - which of the >> extra modules require which libraries? >> >> I would set compile time options accordingly. >> >> This would greatly facilitate my work! >> > one file to look in is Makefile.groups, there you will see lists with > modules organized by common dependencies. In debian, the packages are > generated for each module_group_k... Each such group includes a list of > modules defined in the same file. > > There are some comments giving hints about dependecies, but a better place > is to look in the README of the module, where is a dedicated section for > such details. > > We had some ports done long time ago, you find them in sources > pkg/kamailio/.If you get up to date version, we can replace the old one in > our repository as well. > > Cheers, > Daniel > > -- > Daniel-Constantin Mierla - http://www.asipto.com > http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda > >

10 years, 2 months

Kamailio & dbaliases

by Marino Mileti

Hi to all, is it possible to define same alias for differents SIP ID? How? Documentations of "Alias_DB Module" says: "If the alias resolves to many SIP IDs, the first is replacing the R-URI, the rest are added as branches" ..but i've tried to add more SIPID with the same alias but system doesn't allow it. A.

10 years, 2 months

Multi NIC

by marino.mileti＠alice.it

I've installed Kamailio on multi NIC server (192.168.1.0 & 172.16.1.0), and I've configured rtpproxy in bridged mode in order to manage RTP but I've some trouble during call between endpoint placed on different network. I've find an example regarding Kamailio+RTP in IPv4+IPv6..it's a good point to start but i can't use "af" function... I've tried to replace it with $si but only some call works. How can i replace af correctly? Is there any example conf for my scenario? Many thanks

10 years, 2 months

Crash Kamailio 4.1.5

by Igor Potjevlesch

Hello, A crash just occurred. I use the patch for the PAI issue. I had a look to the core dump and it looks to be another issue: (gdb) bt full #0 0x00000030f2230f30 in escape_string_for_mysql () from /usr/lib64/mysql/libmysqlclient.so.16 No symbol table info available. #1 0x00000030f22269c1 in mysql_real_escape_string () from /usr/lib64/mysql/libmysqlclient.so.16 No symbol table info available. #2 0x00007fb984c0b089 in db_mysql_val2str (_c=0x7fb985033d18, _v=0x7fb981921f60, _s=0x1c51bf0 "0669','<phone_number>','A.B.C.D')", _len=0x7fffab695f74) at km_val.c:79 l = 10 tmp = 1 old_s = 0x1c51bef "'0669','<phone_number>','A.B.C.D')" __FUNCTION__ = "db_mysql_val2str" #3 0x00007fb9847e1137 in db_print_values (_c=0x7fb985033d18, _b=0x1c51b0c "'INVITE','as689f6052','a94c095b773be1dd6e8d668a785a9c847afd0320','361aa4536 ba9cd8463b3ec8114d3711a(a)domain.tld','200','OK','2014-09-16 17:05:26','<phone_number>','<phone_number>@domain.tld','trunk."..., _l=65379, _v=0x7fb981921e00, _n=15, val2str=0x7fb984c0ac88 <db_mysql_val2str>) at db_ut.c:318 i = 11 l = 65152 len = 227 __FUNCTION__ = "db_print_values" #4 0x00007fb9847da028 in db_do_insert_cmd (_h=0x7fb985033d18, _k=0x7fb981921b20, _v=0x7fb981921e00, _n=15, val2str=0x7fb984c0ac88 <db_mysql_val2str>, submit_query=0x7fb984c02092 <db_mysql_submit_query>, mode=0) at db_query.c:224 off = 156 ret = 10 __FUNCTION__ = "db_do_insert_cmd" #5 0x00007fb9847da3b9 in db_do_insert (_h=0x7fb985033d18, _k=0x7fb981921b20, _v=0x7fb981921e00, _n=15, val2str=0x7fb984c0ac88 <db_mysql_val2str>, submit_query=0x7fb984c02092 <db_mysql_submit_query>) at db_query.c:249 No locals. #6 0x00007fb984c04419 in db_mysql_insert (_h=0x7fb985033d18, _k=0x7fb981921b20, _v=0x7fb981921e00, _n=15) at km_dbase.c:415 No locals. #7 0x00007fb98170b783 in acc_db_request (rq=0x7fb9797ab0c8) at acc.c:492 m = 15 n = 2038083784 i = 15 t = 0x414cc0 __FUNCTION__ = "acc_db_request" #8 0x00007fb981715bc8 in acc_onreply (t=0x7fb979775070, req=0x7fb9797ab0c8, reply=0x7fb98504fc48, code=200) at acc_logic.c:471 new_uri_bk = {s = 0x7fb97971e1af "sip:<phone_number>@domain.tld SIP/2.0\r\nRecord-Route: <sip:A.B.C.D;lr=on>\r\nVia: SIP/2.0/UDP A.B.C.D;branch=z9hG4bK6a0a.6c2a27c22049161f515e9c9ac1ffe7e1.0\r\nVia: SIP/2.0/UDP 172.16.3.105:5060;branch=z9hG4bK4"..., len = 19} br = 0 hdr = 0x7fb98171cc20 __FUNCTION__ = "acc_onreply" #9 0x00007fb98171630a in tmcb_func (t=0x7fb979775070, type=512, ps=0x7fffab6962e0) at acc_logic.c:573 __FUNCTION__ = "tmcb_func" #10 0x00007fb98391046c in run_trans_callbacks_internal (cb_lst=0x7fb9797750e0, type=512, trans=0x7fb979775070, params=0x7fffab6962e0) at t_hooks.c:290 cbp = 0x7fb979633b38 backup_from = 0x934630 backup_to = 0x934638 backup_dom_from = 0x934640 backup_dom_to = 0x934648 backup_uri_from = 0x934620 backup_uri_to = 0x934628 backup_xavps = 0x934760 __FUNCTION__ = "run_trans_callbacks_internal" #11 0x00007fb98391067e in run_trans_callbacks_with_buf (type=512, rbuf=0x7fb979775130, req=0x7fb9797ab0c8, repl=0x7fb98504fc48, flags=200) at t_hooks.c:336 params = {req = 0x7fb9797ab0c8, rpl = 0x7fb98504fc48, param = 0x7fb979633b48, code = 200, flags = 200, branch = 0, t_rbuf = 0x7fb979775130, dst = 0x7fb979775180, send_buf = { s = 0x7fb9796f4070 "SIP/2.0 200 OK\r\nVia: SIP/2.0/UDP 172.16.3.105:5060;branch=z9hG4bK49e57236;rport=5060\r\nCall-ID: 361aa4536ba9cd8463b3ec8114d3711a(a)domain.tld\r\nFrom: \"<phone_number>\" <sip:<phone_number>@domain.tld>;t"..., len = 925}} trans = 0x7fb979775070 #12 0x00007fb983942bfa in relay_reply (t=0x7fb979775070, p_msg=0x7fb98504fc48, branch=0, msg_status=200, cancel_data=0x7fffab696640, do_put_on_wait=1) at t_reply.c:2001 relay = 0 save_clone = 0 buf = 0x7fb98505ddd0 "SIP/2.0 200 OK\r\nVia: SIP/2.0/UDP 172.16.3.105:5060;branch=z9hG4bK49e57236;rport=5060\r\nCall-ID: 361aa4536ba9cd8463b3ec8114d3711a(a)domain.tld\r\nFrom: \"<phone_number>\" <sip:<phone_number>@domain.tld>;t"... res_len = 925 relayed_code = 200 relayed_msg = 0x7fb98504fc48 reply_bak = 0x7fffab696490 bm = {to_tag_val = {s = 0x7fb979776608 "", len = 5449371}} totag_retr = 0 reply_status = RPS_COMPLETED uas_rb = 0x7fb979775130 to_tag = 0x0 reason = {s = 0x1ab696440 <Address 0x1ab696440 out of bounds>, len = 1} onsend_params = {req = 0x200924a04, rpl = 0x7fb983962f90, param = 0x414cc0, code = 1, flags = 0, branch = 0, t_rbuf = 0x7fb96f3b4828, dst = 0x7fb98504fe40, send_buf = {s = 0xab696460 <Address 0xab696460 out of bounds>, len = 1024}} __FUNCTION__ = "relay_reply" #13 0x00007fb9839450ab in reply_received (p_msg=0x7fb98504fc48) at t_reply.c:2499 msg_status = 200 last_uac_status = 180 ack = 0x40 <Address 0x40 out of bounds> ack_len = 0 branch = 0 reply_status = -2063230624 onreply_route = 1 cancel_data = {cancel_bitmap = 0, reason = {cause = 200, u = {text = {s = 0x0, len = 9586191}, e2e_cancel = 0x0, packed_hdrs = {s = 0x0, len = 9586191}}}} uac = 0x7fb9797751d8 t = 0x7fb979775070 lack_dst = {send_sock = 0x7fb9850202f0, to = {s = {sa_family = 17952, sa_data = "#\000\000\000\000\000`h\377\204\271\177\000"}, sin = {sin_family = 17952, sin_port = 35, sin_addr = {s_addr = 0}, sin_zero = "`h\377\204\271\177\000"}, sin6 = { sin6_family = 17952, sin6_port = 35, sin6_flowinfo = 0, sin6_addr = {__in6_u = {__u6_addr8 = "`h\377\204\271\177\000\000\220h\377\204\271\177\000", __u6_addr16 = {26720, 34047, 32697, 0, 26768, 34047, 32697, 0}, __u6_addr32 = {2231330912, 32697, 2231330960, 32697}}}, sin6_scope_id = 2231330912}}, id = 32697, proto = 0 '\000', send_flags = {f = 39 '\'', blst_imask = 5 '\005'}} backup_user_from = 0x934630 backup_user_to = 0x934638 backup_domain_from = 0x934640 backup_domain_to = 0x934648 backup_uri_from = 0x934620 backup_uri_to = 0x934628 backup_xavps = 0x934760 replies_locked = 1 branch_ret = 0 prev_branch = -1419155712 blst_503_timeout = 32767 hf = 0x7fb98504fc68 onsend_params = {req = 0x7fffab6966c0, rpl = 0x550bb0, param = 0x2345e0, code = 0, flags = 3, branch = 0, t_rbuf = 0x7fb984e1d380, dst = 0x7fb9850526d0, send_buf = {s = 0x7fffab6966c0 "`G\223", len = 5538065}} ctx = {rec_lev = 0, run_flags = 0, last_retcode = 0, jmp_env = {{__jmpbuf = {140434777374272, -8626733706341394934, 4279488, 140736069201136, 0, 0, -8626733706320423414, 8626919071020996106}, __mask_was_saved = 0, __saved_mask = {__val = {9586419, 901952718779, 124554051613, 9586468, 140434777413984, 9587204, 9586197, 361695345073193192, 9586295, 9586274, 2231736624, 140434777413984, 140434777404704, 140434777374272, 4279488, 140736069201136}}}}} __FUNCTION__ = "reply_received" #14 0x000000000045d853 in do_forward_reply (msg=0x7fb98504fc48, mode=0) at forward.c:777 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 = 32697 r = 1 s = 0x4048504fc50 <Address 0x4048504fc50 out of bounds> len = 0 __FUNCTION__ = "do_forward_reply" #15 0x000000000045e114 in forward_reply (msg=0x7fb98504fc48) at forward.c:860 No locals. #16 0x00000000004a5903 in receive_msg (buf=0x924600 "SIP/2.0 200 OK\r\nVia: SIP/2.0/UDP A.B.C.D;branch=z9hG4bK6a0a.6c2a27c22049161f515e9c9ac1ffe7e1.0;received=A.B.C .D\r\nVia: SIP/2.0/UDP 172.16.3.105:5060;branch=z9hG4bK49e57236;rport=5060\r\nCall-ID: 36"..., len=1028, rcv_info=0x7fffab6969c0) at receive.c:273 msg = 0x7fb98504fc48 ctx = {rec_lev = 8868984, run_flags = 0, last_retcode = 0, jmp_env = {{__jmpbuf = {0, 0, 0, 263853236176, 1, 0, 169733116696, 9586112}, __mask_was_saved = -1419155000, __saved_mask = {__val = {140434775328496, 12884901899, 140434775328496, 4279488, 140736069201136, 140736069200192, 5477982, 0, 140434411832704, 50195, 169369879936, 9586112, 140736069200320, 140736069200240, 5474817, 4279488}}}}} ret = 32697 inb = {s = 0x924600 "SIP/2.0 200 OK\r\nVia: SIP/2.0/UDP A.B.C.D;branch=z9hG4bK6a0a.6c2a27c22049161f515e9c9ac1ffe7e1.0;received=A.B.C .D\r\nVia: SIP/2.0/UDP 172.16.3.105:5060;branch=z9hG4bK49e57236;rport=5060\r\nCall-ID: 36"..., len = 1028} __FUNCTION__ = "receive_msg" #17 0x000000000053c9c4 in udp_rcv_loop () at udp_server.c:536 len = 1028 buf = "SIP/2.0 200 OK\r\nVia: SIP/2.0/UDP A.B.C.D;branch=z9hG4bK6a0a.6c2a27c22049161f515e9c9ac1ffe7e1.0;received=A.B.C .D\r\nVia: SIP/2.0/UDP 172.16.3.105:5060;branch=z9hG4bK49e57236;rport=5060\r\nCall-ID: 36"... tmp = 0x9245c0 "10.143.1.10" from = 0x7fb984f8cd70 fromlen = 16 ri = {src_ip = {af = 2, len = 4, u = {addrl = {336073913, 140434775328496}, addr32 = {336073913, 0, 2229651184, 32697}, addr16 = {5305, 5128, 0, 0, 50928, 34021, 32697, 0}, addr = "\271\024\b\024\000\000\000\000\360\306å ¹\177\000"}}, dst_ip = {af = 2, len = 4, u = {addrl = {67638457, 0}, addr32 = {67638457, 0, 0, 0}, addr16 = {5305, 1032, 0, 0, 0, 0, 0, 0}, addr = "\271\024\b\004", '\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\024\000\000\000\000\000\000\000"}, sin = {sin_family = 2, sin_port = 50195, sin_addr = {s_addr = 336073913}, sin_zero = "\000\000\000\000\000\000\000"}, sin6 = {sin6_family = 2, sin6_port = 50195, sin6_flowinfo = 336073913, 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 = 0x7fb984e5c588, proto = 1 '\001'} __FUNCTION__ = "udp_rcv_loop" #18 0x000000000046d447 in main_loop () at main.c:1617 i = 12 pid = 0 si = 0x7fb984e5c588 si_desc = "udp receiver child=12 sock=A.B.C.D:5060\000\204\271\177\000\000\b\024î ¹\177\000\000\036\205^\000\000\000\000\000\000w^\000\000\000\000\000@K\237@\ 000\000\000\000\300LA\000\000\000\000\000\360li\253\377\177", '\000' <repeats 18 times>, "0ki\253\377\177\000\000\020\245K\000\000\000\000" nrprocs = 15 __FUNCTION__ = "main_loop" #19 0x000000000047054f in main (argc=7, argv=0x7fffab696cf8) at main.c:2545 cfg_stream = 0x1c42010 c = -1 r = 0 tmp = 0x7fffab697f70 "" tmp_len = 0 port = 0 proto = 0 options = 0x5e0a58 ":f:cm:M:dVIhEeb:l:L:n:vKrRDTN:W:w:t:u:g:P:G:SQ:O:a:A:" ret = -1 seed = 1073556037 rfd = 4 debug_save = 0 debug_flag = 0 dont_fork_cnt = 0 n_lst = 0x3d6f60fb88 p = 0x5caba0 "H\211l$\330L\211d$\340H\215-O\244*" __FUNCTION__ = "main" Regards, Igor.

10 years, 2 months

Kamailio v4.1.6 Released

by Daniel-Constantin Mierla

Hello, Kamailio SIP Server v4.1.6 stable release is out. This is a maintenance release of the latest stable branch, 4.1, that includes fixes since release of v4.1.5. There is no change to database schema or configuration language structure that you have to do on installations of v4.1.x. Deployments running previous v4.x.x versions are strongly recommended to be upgraded to v4.1.6. For more details about version 4.1.6 (including links and guidelines to download the tarball or from GIT repository), visit: * http://www.kamailio.org/w/2014/09/kamailio-v4-1-6-released/ Cheers, Daniel -- Daniel-Constantin Mierla - http://www.asipto.com http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda

10 years, 2 months

Registration on SSP

by Alexander Chaliy

Hello, I' trying to register kamailio on SIP Service Provider. In REGISTER reguest I see that URI is like "sip:DOMAIN:PORT;transport=X", but my SSP wait in another schema "sip:DOMAIN". How can I solve it? Thanks. Regards, Alexander Chaliy mobile: +38 097 102 45 83 mail: a.chaliy84(a)gmail.com skype: achaliy

10 years, 2 months

← Newer
1
...
5
6
7
8
9
10
11
...
17
Older →

Jump to page:

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 September 2014