sr-users July 2019

sr-users@lists.kamailio.org

68 participants
76 discussions

WebRTC ACK Protocol
by Ilie Soltanici 08 Jan '20

08 Jan '20

Hello, I am trying to set up a WebRTC2SIP Gateway by using Kamailio and rtpengine. So far, everything is working fine, I'm able to register an extension and make a call, but for some reason, when i'm trying to call a WebRTC extension from any SIP Extension Kamailio is sending INVITE, WebRTC extension is sending back 200 OK, and then Kamailio is trying to send an ACK through UDP protocol, and not through wss, as it's supposed to do. This is how invite is looking: INVITE sip:nl7oe4ss@vjbh7r4im6j7.invalid;transport=wss SIP/2.0 Record-Route: <sip:my-company.net ;transport=udp;ftag=as1789445c;lr=on;nat=yes> Via: SIP/2.0/WSS 123.123.123.123:10443 ;branch=z9hG4bKe655.29d7c135a302f3eb803902d4f5a8da7e.0 Via: SIP/2.0/UDP 192.168.50.237:5060 ;received=192.168.50.237;branch=z9hG4bK7d2e534e;rport=5060 Max-Forwards: 70 From: "WebRTC" <sip:11@my-company.net>;tag=as1789445c To: <sip:15@192.168.50.210:5060> Contact: <sip:11@192.168.50.237:5060> Call-ID: 7fc800de060197fa2315c93763873092(a)my-company.net CSeq: 102 INVITE User-Agent: Proxy Date: Wed, 03 Apr 2019 17:11:41 GMT Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH, MESSAGE Supported: replaces, timer Alert-Info: Content-Type: application/sdp Content-Length: 596 Server: SIP Proxy and then WebRTC app is replying with 200 OK: SIP/2.0 200 OK Record-Route: <sip:my-company.net ;transport=udp;ftag=as1789445c;lr=on;nat=yes> Via: SIP/2.0/WSS 123.123.123.123:10443 ;branch=z9hG4bKe655.29d7c135a302f3eb803902d4f5a8da7e.0 Via: SIP/2.0/UDP 192.168.50.237:5060 ;received=192.168.50.237;branch=z9hG4bK7d2e534e;rport=5060 To: <sip:15@192.168.50.210:5060>;tag=dk4fa8ftt6 From: "WebRTC" <sip:11@my-company.net>;tag=as1789445c Call-ID: 7fc800de060197fa2315c93763873092(a)my-company.net CSeq: 102 INVITE Contact: <sip:nl7oe4ss@vjbh7r4im6j7.invalid;transport=wss> Allow: ACK,CANCEL,INVITE,MESSAGE,BYE,OPTIONS,INFO,NOTIFY,REFER Supported: outbound User-Agent: Proxy-WEBRTC Content-Type: application/sdp Content-Length: 901 and finally, Kamailio is trying to send this ack through UDP protocol: ACK sip:nl7oe4ss@22.22.22.22:57421;transport=wss SIP/2.0 Via: SIP/2.0/UDP 192.168.50.237:5060;branch=z9hG4bK56363ddf;rport Route: <sip:my-company.net;transport=udp;ftag=as1789445c;lr=on;nat=yes> Max-Forwards: 70 From: "WebRTC" <sip:11@my-company.net>;tag=as1789445c To: <sip:15@192.168.50.210:5060>;tag=dk4fa8ftt6 Contact: <sip:11@192.168.50.237:5060> Call-ID: 7fc800de060197fa2315c93763873092(a)my-company.net CSeq: 102 ACK User-Agent: Proxy Content-Length: 0 If i'm trying to force it through TLS, i'm receiving error: get_send_socket2(): protocol/port mismatch (forced tls:123.123.123.123:10443, to udp:22.22.22.22:23317) Can someone point me in the right direction, please? Thank you.

3 4

rtpproxy does not response, disable it
by Zodiac 03 Jan '20

03 Jan '20

Dear friends, I am working on a program on Kamailio and rtpengine proxy. I am wondering whether can I set Kamailio and rtpengine daemon on different physical machines. For example, I set Kamailio on a machine with IP address:10.109.247.80, and launch rtpengine daemon on another machine with interface parameter as 10.109.247.90 and ng port 7723. I set parameter in Kamailio.cfg with modparam(“rtpengine”, “rtpengine_sock”, “udp:10.109.247.90:7723”). Unfortunately I got debug message like this: ERROR: rtpengine [rtpengine.c:1710]: send_rtpp_command(): can't send command to a RTP proxy ERROR: rtpengine [rtpengine.c:1746]: send_rtpp_command(): proxy <udp:10.109.247.90:7723> does not respond, disable it ERROR: rtpengine [rtpengine.c:1616]: rtpp_test(): proxy did not respond to ping And, I also tried to set Kamailio and rtpengine daemon in a same machine,and use modparam(“rtpengine”, “rtpengine_sock”, “udp:localhost:7723”). And Kamailio can work functionally under this situation. rtpengine daemon can receive ping message from Kamailio and rtpengine daemon can work as suspected. So for the later case, is it supposed that Kamailio be in the same machine with same localhost address? Otherwise, what’s the reason for my ERROR? ------------------------------------ 北京邮电大学网络技术研究院网络与交换技术国家重点实验室田军 +86 18810315790 mozillafire(a)bupt.edu.cn ------------------------------------

5 10

Re: [SR-Users] Question on Database Version Table
by JR Richardson 15 Nov '19

15 Nov '19

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 6

Re-invite after RTPengine pacemaker switching?
by Жан Базаров 07 Nov '19

07 Nov '19

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?

3 5

Wrong Record-Route and Via header fields when TCP is used
by Leonid Fainshtein 14 Aug '19

14 Aug '19

Hi, Kamailio server has two legs that are connected to different networks. I'm using Kamailio v.5.2.3 and the "enable_double_rr" is implicitly set to "1". The leg "A" IP address is 10.159.65.1 The leg "B" IP address is 192.168.0.31 The call is initiated from 10.159.65.18 According to the "rr" module documentation, function record_route() should insert two "Record_Route" header fields when a request is accepted on one leg is should go out via the second leg. This works as expected in case of UDP protocol: INVITE sip:2000@192.168.6.106:5460;transport=UDP SIP/2.0 Record-Route: <sip:192.168.0.31;r2=on;lr;did=e2c.a191> Record-Route: <sip:10.159.65.1;r2=on;lr;did=e2c.a191> Via: SIP/2.0/UDP 192.168.0.31;branch=z9hG4bKcfa5.d64ecbd87d5315b5993c4ccf16f86537.0 Via: SIP/2.0/UDP 10.159.65.18:5060;rport=5060;branch=z9hG4bK3a9e9a4d But when the TCP protocol is used then the outbound message looks like this: INVITE sip:2005@192.168.0.178:35058;transport=tcp SIP/2.0 Record-Route: <sip:10.159.65.1;transport=tcp;lr;did=bb6.7dc1> Via: SIP/2.0/TCP 10.159.65.1;branch=z9hG4bKc85a.14afc3867dd3220826f9b9940f78168f.0;i=3 Via: SIP/2.0/TCP 10.159.65.18:5060;rport=58616;branch=z9hG4bK1469331f There are two problems there: a) only one Record-Route with leg is inserted b) the added "Via" header field contains the leg "A" IP address instead of expected leg "B" IP address (192.168.0.31). In the LAN trace I see that in reality the message was sent from leg "B". Is it a bug? Best regards, Leonid Fainshtein

2 13

kamailio as UAC and NAPTR / sendsocket question
by Karsten Horsmann 09 Aug '19

09 Aug '19

Hi List, I try to register to Deutsche Telekom and there product Deutschland Lan siptrunk. Thats works find but i see an intressting behaviour on selecting the right outgoing interface. Kamailio is sending out with tcp the REQUEST via first private ip configured on that server (172.20.120.53). There is no listen directive for that. I forced NAPTR to use tcp or udp and i assume that kamailio got the right dns answers. On the list i read also that i can use force_send_socket to force the outgoing request. Now my idea - hey i use the $rP for the outgoing to select the right outgoing listen directive. $rP - reference to transport protocol of R-URI But to my surprise the logfile told me thats "UDP" - it sends out via TCP (thats okay). Whats an good transport selector variable from kamailio that works? event_route[tm:local-request] { if(!is_method("OPTIONS")) { xlog("L_INFO", "[tm:local-request] request [$rm] from [$fu] to [$ru] [$rP]\n"); } } INFO: <script>: [tm:local-request] request [REGISTER] from [ sip:+49XXXXXXXX@sip-trunk.telekom.de] to [sip:sip-trunk.telekom.de] [UDP] listen=tcp:2xx.xx.xx.xx:5060 listen=udp:2xx.xx.xx.xx:5060 listen=tls:2xx.xx.xx.xx:5061 advertise CFG_EXT_NAME:5061 listen=udp:172.20.120.55:5060 listen=udp:172.20.120.56:5060 listen=udp:172.20.120.57:5060 listen=udp:172.20.120.58:5060 listen=tcp:172.20.120.58:5060 use_dns_cache=on # use internal DNS cache use_dns_failover=on # depends on internal DNS cache dns_srv_loadbalancing=on dns_try_naptr=on dns_retr_time=1 # seconds before retrying a DNS request dns_retr_no=3 # number of DNS retransmissions dns_naptr_ignore_rfc=yes # ignore target NAPTR priority dns_tcp_pref=30 # TCP has second-highest priority dns_udp_pref=10 # use UDP with least priority tcp_connection_lifetime=3605 # set higher than registration expires #dont' restore modparam("uac","restore_mode","none") modparam("uac","restore_dlg",0) ## UAC REGISTER #!ifdef WITH_UAC_REGISTER modparam("uac", "reg_contact_addr", "CFG_PROD_IP") modparam("uac", "reg_timer_interval", 10) modparam("uac", "reg_retry_interval", 10) modparam("uac", "reg_db_url", DBURL) modparam("uac", "restore_mode", "none") modparam("uac", "auth_username_avp", "$avp(AVP_AUTH_USERNAME)") modparam("uac", "auth_password_avp", "$avp(AVP_AUTH_PASSWORD)") modparam("uac", "auth_realm_avp", "$avp(AVP_AUTH_REALM)") #!endif ip a l 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 scope host lo valid_lft forever preferred_lft forever inet6 ::1/128 scope host valid_lft forever preferred_lft forever 2: ens192: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000 link/ether 00:50:56:b5:c1:48 brd ff:ff:ff:ff:ff:ff inet 172.20.120.53/24 brd 172.20.120.255 scope global ens192 valid_lft forever preferred_lft forever inet 2xx.xx.xx.xx/29 scope global ens192 valid_lft forever preferred_lft forever inet 172.20.120.56/24 scope global secondary ens192 valid_lft forever preferred_lft forever inet 172.20.120.57/24 scope global secondary ens192 valid_lft forever preferred_lft forever inet 172.20.120.58/24 scope global secondary ens192 valid_lft forever preferred_lft forever inet 172.20.120.55/24 brd 172.20.120.255 scope global secondary ens192 valid_lft forever preferred_lft forever inet6 fe80::250:56ff:feb5:c148/64 scope link valid_lft forever preferred_lft forever default via 172.20.120.253 dev ens192 172.20.120.0/24 dev ens192 proto kernel scope link src 172.20.120.53 2xx.xx.xx.xx/29 dev ens192 proto kernel scope link src 2xx.xx.xx.xx -- Kind Regards Mit freundlichen Grüßen *Karsten Horsmann*

4 9

100% CPU usage after NTP date update
by Benjamin Marty 07 Aug '19

07 Aug '19

Hello, I'm facing the same issue. Is there a solution for this in the meantime? Benjamin https://lists.kamailio.org/pipermail/sr-users/2015-November/090487.html

2 2

Re: [SR-Users] Kamailio v5.2 kamctl alias add problem
by Igor Potjevlesch 04 Aug '19

04 Aug '19

Hi kamailio Users, I meet a problem with the " kamctl alias add" command in the 5.2 version, I saw that the module used to add an alias had changed, and now the command result with an error : [kamailio]# kamctl alias add XXXX@XXXX sip:XXXXX@XXXX { "jsonrpc": "2.0", "error": { "code": 500, "message": "Not enough parameters or wrong format" }, "id": XXXXX } So in the version 5.2, the table aliasdb replace the table alias ? We are using the table alias for the incomming call, and we implemented scripts to add with the command kamctl alias add the information needed in the tavble alias to route the call. But since the version 5.2 we need to add an argument "path" in this command, and we don't know how to put it at "NULL" or how we can use this argument ? Can you help us with this? Bests Regards Igor Le ven. 5 juil. 2019 à 16:57, Igor Potjevlesch <igor.potjevlesch(a)gmail.com> a écrit : > Hi Daniel-Constantin, > > So in the version 5.2, the table aliasdb replace the table alias ? > We are using the table alias for the incomming call, and we implemented > scripts to add with the command kamctl alias add the information needed in > the tavble alias to route the call. > But since the version 5.2 we need to add an argument "path" in this > command, and we don't know how to put it at "NULL" or how we can use this > argument ? > > Can you help us with this? > > Bests Regards > >>

3 3

Reverse Proxy Asterisk - SIP Provider
by Mihai Cezar 04 Aug '19

04 Aug '19

Hi all, I've tried to create a reverse proxy to forward incoming request that came from SIP provider to Asterisk PBX and forward the requests from asterisk to kamailio then sip provider. What i get is that I see the invite, but is like no ACK. Thanks in advance. M kamailio.cfg: #!KAMAILIO # ####### Defined Values ######### # - flags # FLT_ - per transaction (message) flags # FLB_ - per branch flags #!define FLT_ACC 1 #!define FLT_ACCMISSED 2 #!define FLT_ACCFAILED 3 #!define FLT_NATS 5 #!define FLB_NATB 6 #!define FLB_NATSIPPING 7 ####### Global Parameters ######### ### LOG Levels: 3=DBG, 2=INFO, 1=NOTICE, 0=WARN, -1=ERR debug=3 log_stderror=yes memdbg=5 memlog=5 log_facility=LOG_LOCAL0 log_prefix="{$mt $hdr(CSeq) $ci} " children=1 server_id = 10 xavp_via_params = "via" disable_tcp=yes auto_aliases=no listen=udp:0.0.0.0:5060 ####### Modules Section ######## loadmodule "jsonrpcs.so" loadmodule "kex.so" loadmodule "corex.so" loadmodule "tm.so" loadmodule "tmx.so" loadmodule "sl.so" loadmodule "rr.so" loadmodule "pv.so" loadmodule "maxfwd.so" loadmodule "textops.so" loadmodule "siputils.so" loadmodule "xlog.so" loadmodule "sanity.so" loadmodule "ctl.so" loadmodule "cfg_rpc.so" loadmodule "acc.so" loadmodule "counters.so" # ----------------- setting module-specific parameters --------------- # ----- jsonrpcs params ----- modparam("jsonrpcs", "pretty_format", 1) modparam("jsonrpcs", "fifo_name", "/var/run/kamailio/kamailio_rpc.fifo") modparam("jsonrpcs", "dgram_socket", "/var/run/kamailio/kamailio_rpc.sock") modparam("ctl", "binrpc", "unix:/var/run/kamailio/kamailio_ctl") # ----- tm params ----- modparam("tm", "failure_reply_mode", 3) modparam("tm", "fr_timer", 30000) modparam("tm", "fr_inv_timer", 120000) modparam("rr", "enable_full_lr", 0) modparam("rr", "append_fromtag", 0) modparam("acc", "early_media", 0) modparam("acc", "report_ack", 0) modparam("acc", "report_cancels", 0) modparam("acc", "detect_direction", 0) modparam("acc", "log_flag", FLT_ACC) modparam("acc", "log_missed_flag", FLT_ACCMISSED) modparam("acc", "log_extra", "src_user=$fU;src_domain=$fd;src_ip=$si;" "dst_ouser=$tU;dst_user=$rU;dst_domain=$rd") modparam("acc", "failed_transaction_flag", FLT_ACCFAILED) ####### Routing Logic ######## request_route { # per request initial checks route(REQINIT); # CANCEL processing if (is_method("CANCEL")) { if (t_check_trans()) { route(RELAY); } exit; } # handle retransmissions if (!is_method("ACK")) { if(t_precheck_trans()) { t_check_trans(); exit; } t_check_trans(); } # handle requests within SIP dialogs route(WITHINDLG); # record routing for dialog forming requests (in case they are routed) remove_hf("Route"); if (is_method("INVITE|SUBSCRIBE|REFER")) { record_route(); } # account only INVITEs if (is_method("INVITE")) { setflag(FLT_ACC); sl_send_reply("100","Trying"); if ($si == "172.16.16.1") { sl_send_reply("183","Incoming session from Avoxi"); rewritehost("10.1.1.10"); #exit; } else if ($si == "10.1.1.10"){ # receiving response from client sl_send_reply("183","Outgoing session to Avoxi"); #rewritehost("172.16.16.1"); drop; exit; } else { sl_send_reply("500","No configured IP!"); drop; exit; } } if ($rU==$null) { sl_send_reply("484","Address Incomplete"); exit; } # received from main server - send to client and add via tokens for anycast handling via_add_srvid("1"); $xavp(via=>node) = "10.1.1.4"; via_add_xavp_params("1"); route(RELAY); exit; } # Wrapper for relaying requests route[RELAY] { # enable additional event routes for forwarded requests # - serial forking, RTP relaying handling, a.s.o. if (is_method("INVITE|BYE|SUBSCRIBE|UPDATE")) { if(!t_is_set("branch_route")) t_on_branch("MANAGE_BRANCH"); } if (is_method("INVITE|SUBSCRIBE|UPDATE")) { if(!t_is_set("onreply_route")) t_on_reply("MANAGE_REPLY"); } if (is_method("INVITE")) { if(!t_is_set("failure_route")) t_on_failure("MANAGE_FAILURE"); } if (!t_relay()) { sl_reply_error(); } exit; } # Per SIP request initial checks route[REQINIT] { if($ua =~ "friendly-scanner|sipcli|VaxSIPUserAgent") { # silent drop for scanners - uncomment next line if want to reply sl_send_reply("200", "OK"); exit; } if (!mf_process_maxfwd_header("10")) { sl_send_reply("483","Too Many Hops"); exit; } if(is_method("OPTIONS") && uri==myself && $rU==$null) { sl_send_reply("200","Keepalive"); exit; } if(!sanity_check("1511", "7")) { xlog("Malformed SIP message from $si:$sp\n"); exit; } if ($si == "10.1.1.4") { xlog("L_WARN", "$ci|end|dropping message"); exit; } } # Handle requests within SIP dialogs route[WITHINDLG] { if (!has_totag()) return; if (loose_route()) { if (is_method("BYE")) { setflag(FLT_ACC); setflag(FLT_ACCFAILED); } else if ( is_method("NOTIFY") ) { record_route(); } route(RELAY); exit; } if ( is_method("ACK") ) { if ( t_check_trans() ) { route(RELAY); exit; } else { exit; } } sl_send_reply("400","Loop detected"); exit; } # TM manage for outgoing branches branch_route[MANAGE_BRANCH] { xdbg("new branch [$T_branch_idx] to $ru\n"); } # TM manage for incoming replies onreply_route[MANAGE_REPLY] { xdbg("incoming reply\n"); } # TM manage for failure routing cases failure_route[MANAGE_FAILURE] { if (t_is_canceled()) exit; } asterisk - sip.conf [opensips-trunk](sip-provider) fromdomain=10.1.1.10 host=10.1.1.4 context=from-trunk type=friend insecure=invite,port trunk=yes

4 9

(no subject)
by jay binks 02 Aug '19

02 Aug '19

Hey all, looking for a little help. I've been tracking an issue, where a number of SIP Messages ( typically INVITE ) are sent, but Kamailio only see one of them ( the last one). I have verified that the messages are definitely received on the host, as verified with TCPDUMP, but the INVITES never hit the request route block. ( the very first thing is to log the message ) What i've managed to find is, that if I increase worker children, the problem goes away. So I've got a problem, I think I've found the solution, but what I'm struggling with is how to monitor better, so I can be alerted to this in the future. I started by looking at "kamctl stats | grep drop" "core:drop_replies = 14", "core:drop_requests = 10577" however drop_requests seems to include explicit drops in my config. which I do for many reasons, but mainly bad UA or blocked IP's, so this dosnt seem to be what im after. I then went digging in the code ( often the best way to find things ). in receive.c receive_msg() we find some conditions, where we drop the packet ( before calling request route ). right now im looking around line 251 at LM_DBG("dropping the received message\n"); goto error00; Following error00 I see it calls STATS_RX_DROPS which increments stats->received_drops. This is where it gets fun, I cant find where received_drops is ever returned in the stats output. I can see where -SIGUSR1 will trigger this to be dumped, if Kamailio is compiled with that option ( dosnt seem the debian packages are ). however, what im seeking clarification on is, does this get reported in "kamctl stats" Am I just going crazy or is something not quite right here? TLDNR; how do I monitor for Kamailio not having enough worker threads to process incoming messages. FYI I'm seeing about 50Mbps of incoming SIP on this box, and I do perform a decent amount of work on some message types. -- Sincerely Jay

5 7

2026

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