sr-users October 2019

sr-users@lists.kamailio.org

59 participants
82 discussions

by Henning Westerholt

Hello, I have created a "How-To" blog post on using Kamailio as "session border controller" for Microsoft Teams Direct Routing: https://skalatan.de/de/blog/kamailio-sbc-teams You can this way use all the existing possibilities that Kamailio provide to interact with MS Teams as well. Best regards, Henning -- Henning Westerholt - https://skalatan.de/blog/ Kamailio services - https://skalatan.de/services

4 years, 4 months

Re-use TCP connections on different transactions

by Joel Serrano

Hello, I'm setting up a Kamailio instance behind a TCP load balancer (with proxy protocol and NAT routing: meaning Kam stays in the flow all the time). I've managed to get working almost everything we need for our service, except for one thing, and that is for Kam to use existing connections for subsequent transactions: Following this example: [image: image.png] EXT & INT represent the external and internal interface of a LB between the UAC and Kamailio, using TLS on both legs and proxy protocol. Transaction 1: INVITE, 100, 180, 183, 200 OK UAC 1.1.1.1:1111 -> 2.2.2.2:443 (EXT) 3.3.3.3:3333 (INT) -> 7.7.7.7:5060 (Kamailio) Transaction 2: ACK UAC 1.1.1.1:1112 -> 2.2.2.2:443 (EXT) 4.4.4.4:4444 (INT) -> 7.7.7.7:5060 (Kamailio) Transaction 3: BYE Kam 7.7.7.7:5060 -> 3.3.3.3:3333 (INT) 2.2.2.2:443 (EXT) -> 1.1.1.1:1111 UAC My problem is with Transaction 3. In this case the BYE is originated by the callee, and Kam has to send it to the caller. As the TCP load balancer is between Kam and the UAC, Kam has to send it to the LB so then the LB can forward it back to the UAC. This works well for msgs that belong to the same transaction (INVITE, 100, 180, 183, 200 OK) but it fails when they don't belong to the same transaction. Thanks to the newly added $tcp(c_si) and $tcp(c_sp) pseudovars, I can save the internal IP:Port of the LB, so I can send stuff later to it, my problem is that Kam doesn't seem to allow this? On the original INVITE, I use the following to save where I have to reach the UAC: add_contact_alias("$tcp(c_si)", "$tcp(c_sp)", "tls"); Then, handle_ruri_alias() will take care of setting $du to the correct (internal LB) IP:Port so I can reach the UAC, this works. My problem is that Kamailio doesn't identify that there is a valid existing TLS connection still up (from the INVITE), and tries to create a new one (and this obviously doesn't gives all sorts of problems). So when I run handle_ruri_alias(), and $du is set to 3.3.3.3:3333 (from the example above), instead of using the existing connection, Kamailio tries to create a new one. I have a log statement right before with the result of tcp_conid_state(1) (the connid is 1 for this connection) and the $rc is 1 (Connection is OK), but when I tell Kamailio it has to use it I get this in the logs: DEBUG: {1 11726467 BYE gqR1qqNK8B} <core> [core\/tcp_main.c:2060]: tcp_send(): no open tcp connection found, opening new one"} And then the problems begin... I have tried playing around with: tcp_reuse_port tcp_connection_match But no luck..! I also thought it could be a problem of the connection being created on one worker, and a different worker handling BYE transaction, so tested with children=1 and tcp_children=1, but still same problem. A more detailed log: In blue my log statement checking for the status of conid "1", in red Kam not being able to find it, although it exists (as validated by tcp_conid_state(), and even in netstat I can see the connection established). In this log, 35.191.0.66:60271 would be the equivalent of 3.3.3.3:3333 and 104.175.176.242:28157 would be 1.1.1.1:1111 from the example above. ... "message":" DEBUG: {1 11727734 BYE 5-LX4GdI9X} <core> [core\/tcp_main.c:1657]: _tcpconn_find(): found connection by id: 1"} "message":" NOTICE: {1 11727734 BYE 5-LX4GdI9X} <script>: JOEL TEST New request - M=BYE TCP STATUS:1 ID=5-LX4GdI9X"} ... "message":" DEBUG: {1 11727734 BYE 5-LX4GdI9X} nathelper [nathelper.c:1144]: handle_ruri_alias(): setting dst_uri to <sip:35.191.0.66:60271;transport=tls>"} "message":" DEBUG: {1 11727734 BYE 5-LX4GdI9X} nathelper [nathelper.c:1166]: handle_ruri_alias(): rewriting r-uri to <sip:linphone@104.175.176.242:28157;transport=tls>"} "message":" DEBUG: {1 11727734 BYE 5-LX4GdI9X} tm [t_lookup.c:1328]: t_newtran(): msg (0x7f3c884259d0) id=534\/18664 global id=532\/18664 T start=0xffffffffffffffff"} "message":" DEBUG: {1 11727734 BYE 5-LX4GdI9X} tm [t_lookup.c:497]: t_lookup_request(): start searching: hash=63496, isACK=0"} "message":" DEBUG: {1 11727734 BYE 5-LX4GdI9X} tm [t_lookup.c:455]: matching_3261(): RFC3261 transaction matching failed - via branch [z9hG4bK808f.eee2444f92a02cb33e1b7a21f20bc6bb.0]"} "message":" DEBUG: {1 11727734 BYE 5-LX4GdI9X} tm [t_lookup.c:675]: t_lookup_request(): no transaction found"} "message":" DEBUG: {1 11727734 BYE 5-LX4GdI9X} tm [t_hooks.c:336]: run_reqin_callbacks_internal(): trans=0x7f3c83b8c598, callback type 1, id 0 entered"} "message":" DEBUG: {1 11727734 BYE 5-LX4GdI9X} <core> [core\/crypto\/md5utils.c:67]: MD5StringArray(): MD5 calculated: 3071029feb05962b26b53a9664a14210"} "message":" DEBUG: {1 11727734 BYE 5-LX4GdI9X} siputils [checks.c:123]: has_totag(): totag found"} "message":" DEBUG: {1 11727734 BYE 5-LX4GdI9X} rr [loose.c:1095]: check_route_param(): route params checking against [;r2=on;lr=on;ftag=Eb~TbdfTA;did=cab.01e2;nat=yes] (orig: [r2=on;lr=on;ftag=Eb~TbdfTA;did=cab.01e2;nat=yes])"} "message":" DEBUG: {1 11727734 BYE 5-LX4GdI9X} rr [loose.c:1101]: check_route_param(): params are <;r2=on;lr=on;ftag=Eb~TbdfTA;did=cab.01e2;nat=yes>"} "message":" DEBUG: {1 11727734 BYE 5-LX4GdI9X} siputils [checks.c:123]: has_totag(): totag found"} "message":" DEBUG: {1 11727734 BYE 5-LX4GdI9X} <core> [core\/msg_translator.c:161]: check_via_address(): (198.1.54.228, 198.1.54.228, 0)"} "message":" DEBUG: {1 11727734 BYE 5-LX4GdI9X} <core> [core\/tcp_main.c:2060]: tcp_send(): no open tcp connection found, opening new one"} "message":" DEBUG: {1 11727734 BYE 5-LX4GdI9X} <core> [core\/ip_addr.c:229]: print_ip(): tcpconn_new: new tcp connection: 35.191.0.66"} "message":" DEBUG: {1 11727734 BYE 5-LX4GdI9X} <core> [core\/tcp_main.c:1242]: tcpconn_new(): on port 60271, type 3"} "message":" DEBUG: {1 11727734 BYE 5-LX4GdI9X} <core> [core\/tcp_main.c:1561]: tcpconn_add(): hashes: 1446:2350:0, 5"} "message":" DEBUG: {1 11727734 BYE 5-LX4GdI9X} tls [tls_server.c:199]: tls_complete_init(): completing tls connection initialization"} ... So time to seek help from the community, any suggestions/ideas/comments? Sorry if all this sounds confusing, I've tried my best to put in text the whole scenario in and "understandable" way... Is this even doable? Thanks, Joel.

4 years, 4 months

Re: [SR-Users] Question on Database Version Table

by JR Richardson

Yep version_table Set the name of the table holding the table version. Useful if the proxy is sharing a database within a project and during upgrades. Default value is “version”. Example of usage: version_table="version44" That's what I was looking for, perfect! Yes, I added accountcode and notes to my table for internal use, was just making notes on columns I need on the new version upgrade. Thanks. JR On Tue, Jun 18, 2019 at 2:17 PM Daniel-Constantin Mierla <miconda(a)gmail.com> wrote: > > Hello, > > like Alex said, you can have two version tables, one for each versions > of kamailio you play with and use in config the core parameter to set > the name of that table. > > I am actually writing to say that address table never had accountcode > and notes columns. Likely they were added in your deployment for other > purposes or either the default column names were changed. The default > column names are listed at: > > - > https://kamailio.org/docs/db-tables/kamailio-db-5.2.x.html#gen-db-address > > These were the same for rather long time, iirc the recent version number > changed mainly due to with modifications done to the size, not due to > new columns. > > Cheers, > Daniel > > On 18.06.19 20:50, JR Richardson wrote: > > Hey All, > > > > I'm doing some upgrades and noticed database table version numbers > > have increased. > > > > database table adjustments: > > | address | production ver 3 | upgrade 5.2 ver 6 | need to add > > accountcode and notes column > > | dispatcher | production ver 3 | upgrade 5.2 ver 4 | need to add attr column > > | trusted | production ver 5 | upgrade 5.2 ver 6 | need to add > > ruri_pattern and priority column > > > > I run mysql master/slave so I'm concerned about the master database > > not having the correct version numbers or can I just update the > > version number in the table when I do the upgrade of the kamailio > > versions? > > > > Thanks. > > > > JR

4 years, 5 months

Re-invite after RTPengine pacemaker switching?

by Жан Базаров

I need to send re-invite after pacemaker fails over on new rtpengine server. Because new rtpengine dont participate in DTLS handshake and i hear nothing, but silence. I think, may me its would be work. Do you have any idea on this issue?

4 years, 5 months

$jsonrpl(body) empty or malfunctioned during higher traffic

by Michal Škuta

Hello, Kamailio community, we are implementing evapi communication to our Kamailio server. We have implemented and tested it on our testing server. Everything was working OK. Now we are testing it on our production servers with a lot more calls and we have some problems here. Every n seconds we are requesting from Kamailio list of all dialogs. And this list of dialogs (from jsonrpc *dlg.list*) is sent to evapi connection. Here is a snippet of our *Kamailio code*: route[CGR_DLG_LIST] { xlog("L_INFO", "XLOG: $ci [CGR_DLG_LIST] Requested dialog list"); # CGRateS connection is still alive, set check to true $sht(cgrconn=>check) = 1; if $sht(cgrconn=>cgr) == $null { sl_send_reply("503","Charging controller unreachable"); exit; } jsonrpc_exec('{"jsonrpc":"2.0","id":1, "method":"dlg.list","params":[]}'); xlog("L_INFO", "XLOG: $ci [CGR_DLG_LIST] Test1: $jsonrpl(body)"); evapi_relay("{\"event\":\"CGR_DLG_LIST_REPLY\", \"jsonrpl_body\":$jsonrpl(body)}"); } During a higher number of calls Kamailio is generating ERROR messages from evapi module. Here is the syslog: Oct 30 12:02:15 kam-prod /opt/ipgate/kamailio/sbin/kamailio[19512]: INFO: <script>: XLOG: 123 [CGR_DLG_LIST] Requested dialog list Oct 30 12:02:15 kam-prod /opt/ipgate/kamailio/sbin/kamailio[19512]: INFO: <script>: Oct 30 12:02:15 kam-prod /opt/ipgate/kamailio/sbin/kamailio[19512]: DEBUG: evapi [evapi_dispatch.c:740]: _evapi_relay(): relaying event data [ Oct 30 12:02:15 kam-prod /opt/ipgate/kamailio/sbin/kamailio[19512]: ERROR: evapi [evapi_dispatch.c:764]: _evapi_relay(): cannot serialize event Oct 30 12:02:15 kam-prod /opt/ipgate/kamailio/sbin/kamailio[19512]: ERROR: evapi [evapi_mod.c:265]: w_evapi_relay(): failed to relay event: *We are expecting something like this when nobody is calling* Oct 30 14:12:22 kam-test /opt/ipgate/kamailio/sbin/kamailio[32090]: INFO: <script>: XLOG: 123 [CGR_DLG_LIST] Requested dialog list Oct 30 14:12:22 kam-test /opt/ipgate/kamailio/sbin/kamailio[32090]: INFO: <script>: XLOG: 123 [CGR_DLG_LIST] Test1: { #011"jsonrpc":#011"2.0", #011"result":#011[], #011"id":#0111 } Oct 30 14:12:22 kam-test /opt/ipgate/kamailio/sbin/kamailio[32090]: DEBUG: evapi [evapi_dispatch.c:740]: _evapi_relay(): relaying event data [{"event":"CGR_DLG_LIST_REPLY", #011#011#011"jsonrpl_body":{ #011"jsonrpc":#011"2.0", #011"result":#011[], #011"id":#0111 }}] (96) Oct 30 14:12:22 kam-test /opt/ipgate/kamailio/sbin/kamailio[32090]: DEBUG: evapi [evapi_dispatch.c:778]: _evapi_relay(): sending [0x169ff674] [96:{"event":"CGR_DLG_LIST_REPLY", #011#011#011"jsonrpl_body":{ #011"jsonrpc":#011"2.0", #011"result":#011[], #011"id":#0111 }},] (100) Oct 30 14:12:22 kam-test /opt/ipgate/kamailio/sbin/kamailio[32090]: DEBUG: evapi [evapi_dispatch.c:789]: _evapi_relay(): dispatching [0x169ff674] [96:{"event":"CGR_DLG_LIST_REPLY", #011#011#011"jsonrpl_body":{ #011"jsonrpc":#011"2.0", #011"result":#011[], #011"id":#0111 }},] (100) We enabled debug messages for module evapi and are trying to understand where is the problem. To make this work to this state we needed to increase the *pv_buffer* to really big size (2097152). It looks like $jsonrpl(body) is not ready and everything concated with it is not working. Any help or suggestion is welcomed. Sincerely Michal

4 years, 5 months

Module acc - How to get sip_reason/code on log_write_cdr() messages

by David VILLAUME

Hello, I'm trying to get the reason in my cdrs in log_write_cdr() messages while I see It in acc_log_request() messages. Is there a way to retrieve it in log_write_cdr() messages ? Bellow is my config : modparam("acc", "log_level", 1) modparam("acc", "log_facility", "LOG_LOCAL3") modparam("acc", "cdr_log_enable", 1) modparam("acc", "log_flag", 1) modparam("acc", "failed_transaction_flag", 2) modparam("acc", "log_missed_flag", 3) modparam("acc", "report_cancels", 1) modparam("acc", "cdr_on_failed", 1) modparam("acc", "cdr_enable", 1) modparam("acc", "cdr_facility", "LOG_LOCAL3") modparam("acc", "cdr_expired_dlg_enable", 1) modparam("acc", "cdr_start_on_confirmed", 1) modparam("acc", "cdr_extra", "call_id=$ci;src_ip=$si;fU=$fU;")" David VILLAUME

4 years, 5 months

kamailio - failover setup

by Youssef Boujraf

Dear All, I have seen in the new kamailio release 5.3.0, kamailio support for haproxy protocol – both the v1 (human-readable) and v2 (binary) versions of the protocol are supported ( https://www.kamailio.org/w/kamailio-v5-3-0-release-notes/ ) but it seems to be for Database, webserver failover not for kamailio itself. Haproxy is ONLY supporting TCP but not UDP. My question is : I am looking for failover service of kamailio servers looks like haproxy but udp & tcp. - one domain name : sip.secure.com pointing my public ip address. - two kamailio server pointing same database content (user, whitelist, ...) no asterisk or pbx. Kamailio is used Only for signaling (users, whitelist & rtp) Monitoring service : identify who is the kamailio server online, offline and the ability to force all the SIP/RTP/MANAGEMENT connection from Kamailio Srv1 to Kamailio Srv2 and vice-versa ? Thanks for your suggestions. -- Youssef

4 years, 5 months

Routing Blocks - Missing in latest core wiki

by Joel Serrano

Hi, I was looking at the documentation and noticed that "Routing Blocks" section is missing in latest releases... http://www.kamailio.org/wiki/cookbooks/5.2.x/core#routing_blocks is OK But: http://www.kamailio.org/wiki/cookbooks/5.3.x/core#routing_blocks http://www.kamailio.org/wiki/cookbooks/devel/core#routing_blocks Don't exist, have they been moved elsewhere? Thanks! Joel.

4 years, 5 months

Command Line SIP client

by Gaurav Bmotra

hi i m looking for Command Line SIP client , where i can register user form CLI for testing thank you -- *Regards:* Gaurav Kumar

4 years, 5 months

How to intercept an INVITE after waking up (TSILO module) to change SDP

by Oleg Podguyko

Hello everybody! Kamailio works as a Registrar. Additionally, rtpengine is deployed next to it. Using the module rtpgngine I change SDP. Webrtc <-> SIP calls work fine. RTPengine proxies media. It is necessary to understand that when the call comes, I determine what Protocol the call came wss/tcp/udp, and then through the command "rtpengine_manage" change SDP accordingly. Now I have a new task. Wake up mobile customers through push notification. This client may be as WebRTC and also regular SIP. Trying to use TSILO module. # User location service route[LOCATION] { lookup("location"); $var(rc) = $rc; if (is_method("INVITE")) { if (t_newtran()) { route(SEND_PUSH); xlog("L_INFO", "tsilo store\n"); ts_store(); } } switch ($var(rc)) { case 1: xlog("L_INFO", "LOCATION, Subscriber found, RC: $var(rc)\n"); route(RELAY); break; case -1: xlog("L_INFO", "LOCATION, Subscriber doesn't found, RC: $var(rc)\n"); exit; break; case -3: xlog("L_INFO", "LOCATION, Subscriber doesn't found, RC: $var(rc)\n"); send_reply("404", "Not Found"); exit; case -2: xlog("L_INFO", "LOCATION, Method Not Allowed, RC: $var(rc)\n"); send_reply("405", "Method Not Allowed"); exit; } } If a call occurs when the called client is registered, then we go to the route(RELAY), which creates a branch in which I change the SDP. Everything works. route[RELAY] { # enable additional event routes for forwarded requests # - serial forking, RTP relaying handling, a.s.o. if (is_method("INVITE|BYE")) { if(!t_is_set("branch_route")) t_on_branch("MANAGE_BRANCH"); } if (!t_relay()) { sl_reply_error(); } exit; } And already in MANAGE BRANCH the necessary SDP is put. If the called party is not registered. In the beginning everything goes well. I find this caller through a separate server. Send push notification. The client successfully registers on kamailio. # Handle SIP registrations route[REGISTRAR] { if (!is_method("REGISTER")) return; if(isflagset(FLT_NATS)) { setbflag(FLB_NATB); setbflag(FLB_NATSIPPING); } if(isflagset(FLT_SRC_WSS)) { setbflag(FLB_DST_WS); } if (!save("location")) { sl_reply_error(); } ts_append("location", "$tu") exit; } Next I better show a piece of the log: окт 31 14:55:08 /usr/sbin/kamailio[17488]: exec: {1 2 REGISTER cY6rPubTvJ3ZbyxOrrvGHw..} *** cfgtrace:request_route=[REGISTRAR] c=[/etc/kamailio/kamailio.cfg] l=429 a=26 n=ts_append окт 31 14:55:08 /usr/sbin/kamailio[17488]: DEBUG: {1 2 REGISTER cY6rPubTvJ3ZbyxOrrvGHw..} tsilo [ts_append.c:72]: ts_append(): transaction 8800:338205132 found for 1234567890, going to append branches окт 31 14:55:08 /usr/sbin/kamailio[17488]: DEBUG: {1 2 REGISTER cY6rPubTvJ3ZbyxOrrvGHw..} tm [t_lookup.c:1629]: t_lookup_ident_filter(): transaction found окт 31 14:55:08 /usr/sbin/kamailio[17488]: DEBUG: {1 2 REGISTER cY6rPubTvJ3ZbyxOrrvGHw..} registrar [lookup.c:255]: lookup_helper(): contact for [1234567890] found by address окт 31 14:55:08 /usr/sbin/kamailio[17488]: DEBUG: {1 2 REGISTER cY6rPubTvJ3ZbyxOrrvGHw..} registrar [lookup.c:456]: lookup_helper(): instance is окт 31 14:55:08 /usr/sbin/kamailio[17488]: DEBUG: {1 2 REGISTER cY6rPubTvJ3ZbyxOrrvGHw..} tm [t_append_branches.c:77]: t_append_branches(): transaction 8800:338205132 in status 0 окт 31 14:55:08 /usr/sbin/kamailio[17488]: DEBUG: {1 2 REGISTER cY6rPubTvJ3ZbyxOrrvGHw..} tm [t_append_branches.c:99]: t_append_branches(): Call uefn7rvufi112jj5lt91: 0 (1) outgoing branches окт 31 14:55:08 /usr/sbin/kamailio[17488]: DEBUG: {1 2 REGISTER cY6rPubTvJ3ZbyxOrrvGHw..} tm [t_append_branches.c:126]: t_append_branches(): Current uri sip:1234567890@10.10.10.1:58027;transport=TCP;rinstance=727a64a3a59c508f окт 31 14:55:08 /usr/sbin/kamailio[17488]: DEBUG: {1 2 REGISTER cY6rPubTvJ3ZbyxOrrvGHw..} <core> [core/msg_translator.c:162]: check_via_address(): (50.7.93.27, uas7i396ceb5.invalid, 0) окт 31 14:55:08 /usr/sbin/kamailio[17488]: DEBUG: {1 2 REGISTER cY6rPubTvJ3ZbyxOrrvGHw..} tm [t_append_branches.c:149]: t_append_branches(): added branch [sip:1234567890@10.10.10.1:58027;transport=TCP;rinstance=727a64a3a59c508f] with ruid [uloc-5dbacb09-4450-7] окт 31 14:55:08 /usr/sbin/kamailio[17488]: DEBUG: {1 2 REGISTER cY6rPubTvJ3ZbyxOrrvGHw..} tm [t_append_branches.c:163]: t_append_branches(): Call uefn7rvufi112jj5lt91: 0 (0) outgoing branches after clear_branches() окт 31 14:55:08 /usr/sbin/kamailio[17488]: DEBUG: {1 2 REGISTER cY6rPubTvJ3ZbyxOrrvGHw..} <core> [core/tcp_main.c:2238]: tcpconn_send_put(): send from reader (17488 (21)), reusing fd окт 31 14:55:08 /usr/sbin/kamailio[17488]: DEBUG: {1 2 REGISTER cY6rPubTvJ3ZbyxOrrvGHw..} <core> [core/tcp_main.c:2473]: tcpconn_do_send(): sending... окт 31 14:55:08 /usr/sbin/kamailio[17488]: DEBUG: {1 2 REGISTER cY6rPubTvJ3ZbyxOrrvGHw..} <core> [core/tcp_main.c:2507]: tcpconn_do_send(): after real write: c= 0x7fb39dde4c68 n=3131 fd=12 окт 31 14:55:08 /usr/sbin/kamailio[17488]: DEBUG: {1 2 REGISTER cY6rPubTvJ3ZbyxOrrvGHw..} <core> [core/tcp_main.c:2508]: tcpconn_do_send(): buf= Thus, the transaction wakes up and the initial INVITE is sent to the new registered client without any SDP change! Which eventually leads to 415 error. Now the question itself. Tell me! As me at this moment intercept this INVITE, to it has passed through in advance prepared path for changing SDP. Thank you. -- Oleg Podguyko

4 years, 5 months

← Newer
1
2
3
4
5
6
7
8
9
Older →

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 October 2019