sr-users August 2017

sr-users@lists.kamailio.org

89 participants
144 discussions

by Жан Базаров

Hello! provider trunks registration on kamailio UAC?! it's clear. but how does asterisk find out through which trunk the call should be made? I tried to set the header from asterisk dialplan. for example: if (is_method("INVITE")) { #record_route_preset("109.195.102.122"); route(DIRECTION); setflag(FLT_ACC); # do accounting } # ------ LOADBALANCE ROUTE ------------ # if(!ds_is_from_list()) { route(DISPATCH); } route[DISPATCH] { #round robin dispatching on gateways group '1' if(!ds_select_dst("1", "4")) { send_reply("404", "No destination"); exit; } xlog("L_DBG", "--- SCRIPT: going to <$ru> via <$du>\n"); t_on_failure("RTF_DISPATCH"); route(NATMANAGE); route(DRELAY); exit; } route[DIRECTION] { if ($hdr(x-trunk) != $null) { if (!is_method("BYE")){ $fu=""; t_on_failure("MANAGE_FAILURE"); $dlg_ctx(timeout_route) = "DIALOG_END"; $avp(i:10)=43200; $dlg_ctx(timeout_bye) = 0; sql_pvquery("ca", "select l_uuid, auth_username, auth_password, realm, l_domain, r_domain from uacreg where id='$hdr(x-trunk)'", "$avp(uuid), $avp(uname), $avp(passwd), $avp(realm), $avp(src_ipaddr), $avp(dst_ipaddr)"); t_on_failure("MANAGE_FAILURE"); $dlg_ctx(timeout_route) = "DIALOG_END"; $avp(i:10)=43200; $dlg_ctx(timeout_bye) = 0; $fu=""; uac_replace_from("sip:$avp(uname)@$avp(dst_ipaddr)"); $tu="sip:"+$tU+"@"+$avp(dst_ipaddr); $ru="sip:"+$tU+"@"+$avp(dst_ipaddr); remove_hf("Contact"); $var(contact)="sip:"+$avp(uname)+"@10.49.9.2:5060"; insert_hf("Contact: <$var(contact)>\r\n"); #insert_hf("Contact: "); msg_apply_changes(); fix_nated_register(); xlog("L_INFO","Contact header $var(contact) 111111111111111111111111111111111111111 is $ct {$ct}\n"); route(RELAY); } #### BYE } ### XTRUNK But in this configuration I do not come bye but when I register providers trunks on asterisk - problem with BYE not visible. but I can not register provider-trunks on all the asterisks, because incoming invite arrives at the link + address, and all the asteriscs ring. All my asterisk's behind nat

7 years, 2 months

jsonrpcs execution error

by David Villasmil

Hello guys, i configured jsonrpc on kamailio.cfg and RPCFIFOPATH on kamctlrc to the same file, seems to work for some commands, but not for others: root@ip-172-31-30-160:/home/admin# kamctl trusted show +----+--------------+-------+--------------+--------------+------+----------+ | id | src_ip | proto | from_pattern | ruri_pattern | tag | priority | +----+--------------+-------+--------------+--------------+------+----------+ | 1 | 1.2.3.4 | udp | | NULL | | 0 | | 2 | 5.4.3.2 | udp | | NULL | | 0 | +----+--------------+-------+--------------+--------------+------+----------+ root@ip-172-31-30-160:/home/admin# kamctl trusted dump { "jsonrpc": "2.0", "error": { "code": -32000, "message": "Execution Error" }, "id": 32022 } root@ip-172-31-30-160:/home/admin# kamctl trusted reload { "jsonrpc": "2.0", "error": { "code": -32000, "message": "Execution Error" }, "id": 32041 } Any help? Thanks! Regards, David Villasmil email: david.villasmil.work(a)gmail.com phone: +34669448337 ᐧ

7 years, 2 months

Carrierroute, uac_*, failure_route.

by yu＠yu-boot.ru

Hello. Have a following task. Select carrier by carrierroute module from db, try to route (dial, relay, bridge - you name it) call there and if call is failed/rejected due to any reason, go to failure_route(?), perform carrierroute lookup again for another carrier and route call there. Main problem is that different carriers require different From/To format. And Kamailio don't allow to use uac* functions in failure_route. How to resolve this? Maybe entire routing method is wrong for my task? Any advice? -- sent from myMail for Android

7 years, 2 months

Change on the fly logging verbosity - Kamailio v5.0.2

by Karsten Horsmann

Hello, at this moment i try to figure out the best way to add an "switch" for debug/log output. I use many xlog, like everyone that starts with kamailio too. Then i go further and add #!ifdef cases around to switch this via #!define. Is there any other way to turn on/off my "debug"-logging on the fly, while kamailio is still running? #!define TESTBED_MODE request_route{ ... #!ifdef TESTBED_MODE route(DEBUG); #!endif ... #!ifdef TESTBED_MODE xlog("L_INFO","---FIX_SIPS-after: ru:($ru)"); #!endif ... } -- Kind Regards *Karsten Horsmann*

7 years, 2 months

Planning Kamailio v5.0.3

by Daniel-Constantin Mierla

Hello, I am considering to release Kamailio v5.0.3 sometime next week, therefore it is the time to backport patches with fixes from master that apply to 5.0 branch. If you are aware of such fix that has to be backported, reply here or make a pull request on github project. 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

7 years, 2 months

Kamailio SIP protocol over WSS

by Washington Costa

Hello, I'm using kamailio 5.0.2 (x86_64/linux). And it works with WS. Regards, Washington Costa

7 years, 2 months

Kamailio SIP protocol over WSS

by Washington Costa

Hi. I'm trying use the JSSIP cliente and Kamailio with WSS. On these sites I generated my certificates: https://letsencrypt.org/ and https://certbot.eff.org/ My browser identify the certificates but SIP client just say: failed: WebSocket opening handshake was canceled Do you have any idea how to fix it? Do you can say a checklist with everything I need to do for use Kamailio with WSS? Here is my log on Kamailio: Aug 31 09:10:10 ip-172-31-39-220 kamailio[13183]: 33(13239) DEBUG: <core> [core/ip_addr.c:229]: print_ip(): tcpconn_new: new tcp connection: 187.41.60.10 Aug 31 09:10:10 ip-172-31-39-220 kamailio[13183]: 33(13239) DEBUG: <core> [core/tcp_main.c:985]: tcpconn_new(): on port 44630, type 3 Aug 31 09:10:10 ip-172-31-39-220 kamailio[13183]: 33(13239) DEBUG: <core> [core/tcp_main.c:1291]: tcpconn_add(): hashes: 3062:1194:1491, 2 Aug 31 09:10:10 ip-172-31-39-220 kamailio[13183]: 33(13239) DEBUG: <core> [core/io_wait.h:380]: io_watch_add(): DBG: io_watch_add(0xa4ac60, 53, 2, 0x7f259df9cd80), fd_no=44 Aug 31 09:10:10 ip-172-31-39-220 kamailio[13183]: 33(13239) DEBUG: <core> [core/io_wait.h:602]: io_watch_del(): DBG: io_watch_del (0xa4ac60, 53, -1, 0x0) fd_no=45 called Aug 31 09:10:10 ip-172-31-39-220 kamailio[13183]: 33(13239) DEBUG: <core> [core/tcp_main.c:4139]: handle_tcpconn_ev(): sending to child, events 1 Aug 31 09:10:10 ip-172-31-39-220 kamailio[13183]: 33(13239) DEBUG: <core> [core/tcp_main.c:3818]: send2child(): selected tcp worker 1 26(13225) for activity on [tls:172.31.39.220:4443], 0x7f259df9cd80 Aug 31 09:10:10 ip-172-31-39-220 kamailio[13183]: 26(13225) DEBUG: <core> [core/tcp_read.c:1574]: handle_io(): received n=8 con=0x7f259df9cd80, fd=9 Aug 31 09:10:10 ip-172-31-39-220 kamailio[13183]: 26(13225) DEBUG: tls [tls_server.c:197]: tls_complete_init(): completing tls connection initialization Aug 31 09:10:10 ip-172-31-39-220 kamailio[13183]: 26(13225) DEBUG: tls [tls_server.c:226]: tls_complete_init(): Using initial TLS domain TLSs<default> (dom 0x7f259ddc4a80 ctx 0x7f259de03bc0 sn []) Aug 31 09:10:10 ip-172-31-39-220 kamailio[13183]: 26(13225) DEBUG: tls [tls_domain.c:715]: sr_ssl_ctx_info_callback(): SSL handshake started Aug 31 09:10:10 ip-172-31-39-220 kamailio[13183]: 26(13225) DEBUG: <core> [core/tcp_main.c:2430]: tcpconn_do_send(): sending... Aug 31 09:10:10 ip-172-31-39-220 kamailio[13183]: 26(13225) DEBUG: <core> [core/tcp_main.c:2464]: tcpconn_do_send(): after real write: c= 0x7f259df9cd80 n=2568 fd=9 Aug 31 09:10:10 ip-172-31-39-220 kamailio[13183]: 26(13225) DEBUG: <core> [core/tcp_main.c:2465]: tcpconn_do_send(): buf= Aug 31 09:10:10 ip-172-31-39-220 kamailio[13183]: #026#003#001 Aug 31 09:10:10 ip-172-31-39-220 kamailio[13183]: 26(13225) DEBUG: <core> [core/io_wait.h:380]: io_watch_add(): DBG: io_watch_add(0xa93f00, 9, 2, 0x7f259df9cd80), fd_no=1 Aug 31 09:10:10 ip-172-31-39-220 kamailio[13183]: 26(13225) DEBUG: <core> [core/tcp_read.c:195]: tcp_emit_closed_event(): TCP closed event creation triggered Aug 31 09:10:10 ip-172-31-39-220 kamailio[13183]: 26(13225) DEBUG: <core> [core/tcp_read.c:202]: tcp_emit_closed_event(): no callback registering for handling TCP closed event - dropping! Aug 31 09:10:10 ip-172-31-39-220 kamailio[13183]: 26(13225) DEBUG: <core> [core/tcp_read.c:305]: tcp_read_data(): EOF on 0x7f259df9cd80, FD 9 ([187.41.60.10]:44630 ->26(13225) DEBUG: <core> [core/tcp_read.c:306]: tcp_read_data(): -> [172.31.39.220]:4443) Aug 31 09:10:10 ip-172-31-39-220 kamailio[13183]: 26(13225) DEBUG: <core> [core/tcp_read.c:1341]: tcp_read_req(): EOF Aug 31 09:10:10 ip-172-31-39-220 kamailio[13183]: 26(13225) DEBUG: <core> [core/io_wait.h:602]: io_watch_del(): DBG: io_watch_del (0xa93f00, 9, -1, 0x10) fd_no=2 called Aug 31 09:10:10 ip-172-31-39-220 kamailio[13183]: 26(13225) DEBUG: <core> [core/tcp_read.c:1495]: release_tcpconn(): releasing con 0x7f259df9cd80, state -1, fd=9, id=2 ([187.41.60.10]:44630 -> [187.41.60.10]:4443) Aug 31 09:10:10 ip-172-31-39-220 kamailio[13183]: 26(13225) DEBUG: <core> [core/tcp_read.c:1499]: release_tcpconn(): extra_data 0x7f259dfb6488 Aug 31 09:10:10 ip-172-31-39-220 kamailio[13183]: 33(13239) DEBUG: <core> [core/tcp_main.c:3250]: handle_tcp_child(): reader response= 7f259df9cd80, -1 from 1 Aug 31 09:10:10 ip-172-31-39-220 kamailio[13183]: 33(13239) DEBUG: tls [tls_server.c:665]: tls_h_close(): Closing SSL connection 0x7f259dfb6488 Aug 31 09:10:17 ip-172-31-39-220 kamailio[13183]: 33(13239) DEBUG: <core> [core/ip_addr.c:229]: print_ip(): tcpconn_new: new tcp connection: 187.41.60.10 Aug 31 09:10:17 ip-172-31-39-220 kamailio[13183]: 33(13239) DEBUG: <core> [core/tcp_main.c:985]: tcpconn_new(): on port 44692, type 3 Aug 31 09:10:17 ip-172-31-39-220 kamailio[13183]: 33(13239) DEBUG: <core> [core/tcp_main.c:1291]: tcpconn_add(): hashes: 2869:1129:1296, 3 Aug 31 09:10:17 ip-172-31-39-220 kamailio[13183]: 33(13239) DEBUG: <core> [core/io_wait.h:380]: io_watch_add(): DBG: io_watch_add(0xa4ac60, 53, 2, 0x7f259df9cd80), fd_no=44 Aug 31 09:10:17 ip-172-31-39-220 kamailio[13183]: 33(13239) DEBUG: <core> [core/io_wait.h:602]: io_watch_del(): DBG: io_watch_del (0xa4ac60, 53, -1, 0x0) fd_no=45 called Aug 31 09:10:17 ip-172-31-39-220 kamailio[13183]: 33(13239) DEBUG: <core> [core/tcp_main.c:4139]: handle_tcpconn_ev(): sending to child, events 1 Aug 31 09:10:17 ip-172-31-39-220 kamailio[13183]: 33(13239) DEBUG: <core> [core/tcp_main.c:3818]: send2child(): selected tcp worker 2 27(13226) for activity on [tls:172.31.39.220:4443], 0x7f259df9cd80 Aug 31 09:10:17 ip-172-31-39-220 kamailio[13183]: 27(13226) DEBUG: <core> [core/tcp_read.c:1574]: handle_io(): received n=8 con=0x7f259df9cd80, fd=9 Aug 31 09:10:17 ip-172-31-39-220 kamailio[13183]: 27(13226) DEBUG: tls [tls_server.c:197]: tls_complete_init(): completing tls connection initialization Aug 31 09:10:17 ip-172-31-39-220 kamailio[13183]: 27(13226) DEBUG: tls [tls_server.c:226]: tls_complete_init(): Using initial TLS domain TLSs<default> (dom 0x7f259ddc4a80 ctx 0x7f259de05708 sn []) Aug 31 09:10:17 ip-172-31-39-220 kamailio[13183]: 27(13226) DEBUG: tls [tls_domain.c:715]: sr_ssl_ctx_info_callback(): SSL handshake started Aug 31 09:10:17 ip-172-31-39-220 kamailio[13183]: 27(13226) DEBUG: <core> [core/tcp_main.c:2430]: tcpconn_do_send(): sending... Aug 31 09:10:17 ip-172-31-39-220 kamailio[13183]: 27(13226) DEBUG: <core> [core/tcp_main.c:2464]: tcpconn_do_send(): after real write: c= 0x7f259df9cd80 n=2568 fd=9 Aug 31 09:10:17 ip-172-31-39-220 kamailio[13183]: 27(13226) DEBUG: <core> [core/tcp_main.c:2465]: tcpconn_do_send(): buf= Aug 31 09:10:17 ip-172-31-39-220 kamailio[13183]: #026#003#001 Aug 31 09:10:17 ip-172-31-39-220 kamailio[13183]: 27(13226) DEBUG: <core> [core/io_wait.h:380]: io_watch_add(): DBG: io_watch_add(0xa93f00, 9, 2, 0x7f259df9cd80), fd_no=1 Aug 31 09:10:17 ip-172-31-39-220 kamailio[13183]: 27(13226) DEBUG: <core> [core/tcp_read.c:195]: tcp_emit_closed_event(): TCP closed event creation triggered Aug 31 09:10:17 ip-172-31-39-220 kamailio[13183]: 27(13226) DEBUG: <core> [core/tcp_read.c:202]: tcp_emit_closed_event(): no callback registering for handling TCP closed event - dropping! Aug 31 09:10:17 ip-172-31-39-220 kamailio[13183]: 27(13226) DEBUG: <core> [core/tcp_read.c:305]: tcp_read_data(): EOF on 0x7f259df9cd80, FD 9 ([187.41.60.10]:44692 ->27(13226) DEBUG: <core> [core/tcp_read.c:306]: tcp_read_data(): -> [172.31.39.220]:4443) Aug 31 09:10:17 ip-172-31-39-220 kamailio[13183]: 27(13226) DEBUG: <core> [core/tcp_read.c:1341]: tcp_read_req(): EOF Aug 31 09:10:17 ip-172-31-39-220 kamailio[13183]: 27(13226) DEBUG: <core> [core/io_wait.h:602]: io_watch_del(): DBG: io_watch_del (0xa93f00, 9, -1, 0x10) fd_no=2 called Aug 31 09:10:17 ip-172-31-39-220 kamailio[13183]: 27(13226) DEBUG: <core> [core/tcp_read.c:1495]: release_tcpconn(): releasing con 0x7f259df9cd80, state -1, fd=9, id=3 ([187.41.60.10]:44692 -> [187.41.60.10]:4443) Aug 31 09:10:17 ip-172-31-39-220 kamailio[13183]: 27(13226) DEBUG: <core> [core/tcp_read.c:1499]: release_tcpconn(): extra_data 0x7f259dfb6488 Aug 31 09:10:17 ip-172-31-39-220 kamailio[13183]: 33(13239) DEBUG: <core> [core/tcp_main.c:3250]: handle_tcp_child(): reader response= 7f259df9cd80, -1 from 2 Aug 31 09:10:17 ip-172-31-39-220 kamailio[13183]: 33(13239) DEBUG: tls [tls_server.c:665]: tls_h_close(): Closing SSL connection 0x7f259dfb6488

7 years, 2 months

question for best way to remove sips uris - TLS and sips in $ru - get_send_socket2(): protocol/port mismatch

by Karsten Horsmann

Hello List, of course - best way is not to use sips: uri scheme. But i have to deal with that. I try to configure an multihomed kamailio (public/private IP) in front of my SIP-Servers. One of my softphones variants used TLS for connection but the INVITES of this softphone use the "sips" URI scheme. As i saw in other posts, this seems to be an issue for many people. In my case it breaks the routing to my internal sip-server (only plain udp). Most of my config is similar to havfos example + TLS. https://github.com/havfo/WEBRTC-to-SIP/blob/master/etc/kamailio/kamailio.cfg I tried to fixed that with this extra route - but this breaks the dialog somewhere - after 60 seconds i have no audio and the BYE becomes another CSeq: in the request_route right after route(AUTH) i add my route(FIX_SIPS) if (is_method("INVITE|SUBSCRIBE")) { if ($ru =~ "^sips:") { route(FIX_SIPS); } else { record_route(); } } route[FIX_SIPS] { if ($ru =~ "^sips:") { xlog("L_INFO","---FIX_SIPS-before: ru:($ru)"); $var(orig_uri) = $ru; $ru = "sip:" + $rU + "@" + $td; xlog("L_INFO","---FIX_SIPS-now: $rU $td ru:($ru) orig_uri:($var(orig_uri))"); record_route(); #$ru = $var(orig_uri); xlog("L_INFO","---FIX_SIPS-after: ru:($ru)"); } } 172.20.120.81 = Kamailio private IP 172.20.120.79 = My internal SIP-Server (B2BUA) I used kamailio with CentOS 7 and RTPENGINE 63bdd615 from master kamailio-5.0.2-3.1.x86_64 kamailio-tls-5.0.2-3.1.x86_64 kamailio-mysql-5.0.2-3.1.x86_64 kamailio-websocket-5.0.2-3.1.x86_64 -- Kind Regards *Karsten Horsmann*

7 years, 2 months

sql_do_query_async(): the db driver module doesn't support async query

by Juha Heinanen

sqlops README tells: 4.5. sql_query_async(connection, query) Make an async SQL query using 'connection', if implemented by db driver module (e.g., db_mysql) my sqlops sqlcon parameter specifies mysql driver, but still i get to syslog: Aug 24 08:02:05 rox1 /usr/bin/sip-proxy[13886]: ERROR: sqlops [sql_api.c:427]: sql_do_query_async(): the db driver module doesn'tsupport async query any idea why? -- juha

7 years, 2 months

kamailio asterisk + provider sip trunks

by Жан Базаров

Good morning! kamailio + dispatcher + provider trunks. How to make RR for incoming calls from pstn? my trunks are authorized on an asterisk, but i have problem with multiple calls on each asterisk. If I do through uac then I have a problem with BYE, and in general the module is uncomfortable. Please tell me how to implement a bunch: kamailio + asterisk + provider trunks..

7 years, 2 months

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 August 2017