sr-users July 2019

sr-users@lists.kamailio.org

68 participants
72 discussions

Wrong Record-Route and Via header fields when TCP is used

by Leonid Fainshtein

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

4 years, 8 months

kamailio as UAC and NAPTR / sendsocket question

by Karsten Horsmann

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 years, 8 months

100% CPU usage after NTP date update

by Benjamin Marty

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

4 years, 8 months

Re: [SR-Users] Kamailio v5.2 kamctl alias add problem

by Igor Potjevlesch

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

4 years, 8 months

Reverse Proxy Asterisk - SIP Provider

by Mihai Cezar

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 years, 8 months

(no subject)

by jay binks

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

4 years, 8 months

Deleting extra location attribute(location_attrs table) when contact is expired

by Pintu Lohar

Hi All, Regarding modparam("tm|usrloc", "xavp_contact", "ulattrs") #ref : https://www.kamailio.org/docs/modules/devel/modules/usrloc.html#usrloc.p.xa… . There is some requirement where we need to save some extra location attributes to location_attrs <https://kamailio.org/docs/db-tables/kamailio-db-4.3.x.html#gen-db-location-…> tables $xavp(ulattrs=>deviceIdentify)= "Some str values" and calling save(“location”) , It works well and saved location attribute table but But when contact expired callback is received, udomain_contact_expired_db() does not it delete the extra location attribute from database but deleting the record from location table only ? If not, is there any recommended approach to delete the extra location attributes from the database? or am I missing something to set? Alternate I was thinking could be running timer from Kamailio config and check last_modified time and delete those(based on our UAC expiry setting), is it the right approach. Kamailio Version: 5.2.0. Thanks for your valuable suggestion in advance. Regards Pintu Lohar

4 years, 8 months

by José Antonio Gutiérrez Delgado

Hello, I would like to know if it is possible to enable registration for users that have not been created with kamctl. For example, if I can register a user with a random name without a password, or obtain from another database other than kamailio; I would also like it to be allowed at the same time as there are users with password registered with kamctl. Thanks you, José Antonio Gutiérrez Delgado Responsable técnico Oficina: (+34) 923040031 <http://www.arsoft-company.com> *De conformidad a lo establecido en el REGLAMENTO (UE) 2016/679 DEL PARLAMENTO EUROPEO Y DEL CONSEJO de 27 de abril de 2016 relativo a la protección de las personas físicas en lo que respecta al tratamiento de datos personales y a la libre circulación de estos datos y por el que se deroga la Directiva 95/46/CE (Reglamento general de protección de datos), le informamos que todos los datos pasaran a formar parte de un fichero automatizado cuyo responsable es AUGMENTED REALITY SOFTWARE S.L siendo la única finalidad de dicho fichero la gestión de carácter comercial y el posible envío de comunicaciones comerciales sobre nuestros productos. Si lo desea puede ejercer sus derechos de acceso, rectificación, cancelación y oposición de sus datos en C/ Duero 12, Parque Científico, ARSOFT, 37185 o enviando un mensaje electrónico a info(a)arsoft-company.com <info(a)arsoft-company.com> indicando en el asunto el derecho que desea ejercitar.Este mensaje y sus archivos adjuntos van dirigidos exclusivamente a su destinatario, pudiendo contener información confidencial sometida a secreto profesional. No está permitida su reproducción o distribución sin nuestra autorización expresa. Si usted no es el destinatario final por favor elimínelo e infórmenos por esta vía.*

4 years, 9 months

Dialog missing when BYE is received from trunk

by Andrew White

Hi all, I’ve got a call flow where PBX makes a call via Kamailio, which uses the UAC modules to make the call to the trunk. This works great, however I’ve noticed recently that when the BYE comes from the trunk, Kamailio doesn’t recognise the dialog and throws back a 404. Due to this, the PBX never knows the session has ended, and keeps its session open. Here’s the flow from Wireshark: https://i.imgur.com/BxPRrXP.png <https://i.imgur.com/BxPRrXP.png> As you can see, the BYE is received from the trunk, and Kamailio throws a 404. I checked with an rpc dlg.list and at this point the dialog had gone. 30 seconds later, I threw a BYE from the PBX, and because the dialog no longer existed, it got a 481 back. The INVITE to the trunk has the following Record-Route header: Record-Route: <sip:kamailio.public-ip;lr;ftag=mjKtcKaBteQ4Q;vst=AAAAAAYFBQUHAwYHBgRzMwIRGRMcAgJBWBEVCwAbBhtADxBjdGVkLmNvbS5hdQ--;did=624.b2e1> When the first BYE comes in, it still has same did in the Route header. Below I’ve put the output from the dialog list rpc call (before the first BYE) and the relevant log lines. { h_entry: 1062 h_id: 7723 ref: 2 call-id: a9d32620-2b68-1238-048a-0cc47a18705a from_uri: sip:61400123123@pbx.local:5060 to_uri: sip:61400123123@10.0.0.2 state: 4 start_ts: 1564269942 init_ts: 1564269929 end_ts: 0 timeout: 1564313142 lifetime: 43200 dflags: 643 sflags: 0 iflags: 16 caller: { tag: mjKtcKaBteQ4Q contact: sip:pbx.local cseq: 7581172 route_set: socket: udp:10.0.0.2:5060 } callee: { tag: SD5ptp899-1177933201-1564269931305 contact: sip:SDd3mt8-nn9jnirnmqcrvfmvkpm0hmhvgggjgv2io788of70s84u9@trunk.remote:5060;transport=udp cseq: 0 route_set: socket: udp:10.0.0.2:5060 } profiles: { } variables: { { cseq_diff: 1 } } } Jul 28 09:27:30 ip-10-0-0-2 /usr/local/sbin/kamailio[11061]: NOTICE: {2 450917085 BYE a9d32620-2b68-1238-048a-0cc47a18705a} acc [acc.c:279]: acc_log_request(): ACC: transaction answered: timestamp=1564270050;method=BYE;from_tag=SD5ptp899-1177933201-1564269931305;to_tag=mjKtcKaBteQ4Q;call_id=a9d32620-2b68-1238-048a-0cc47a18705a;code=404;reason=Not here;src_user=0400123123;src_domain=trunk.remote;src_ip=trunk.remote;dst_ouser=0400123123;dst_user=0400123123;dst_domain=kamailio.public-ip I’m assuming the 404 is because the Contact header I sent from Kamailio -> Trunk is rewritten, that Contact is Kamailio’s public contact IP. However the dialog has the caller contact within it referencing back to the local PBX, so I would think when Kamailio gets this dialog ID back with a BYE it would relay it back to the original contact, wouldn’t it? Thanks! Andrew

4 years, 9 months

IMS_ISC technical specification

by Ali Shirvani

Hi all, I read some portion of imc_isc_mod.c, specially isc_from_as function. In that function there is some function call that searching for some marks in the SIP message. Also I read section 5.7.3 from TS 24.229 but I didn't find the marking mechanism that used in isc_from_as function. Would you please point me to the technical specification that implemented in IMS_ISC module? Regards, Ali

4 years, 9 months

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