sr-users April 2024

sr-users@lists.kamailio.org

69 participants
63 discussions

by James Lipski

Hello, I have remote users registering/ routing calls through my server. When calls do pass through the server, the server updates the from name, to uri and from uri via updating the pseudovariables $fn, $tu, and $fu respectively. While this is has been working, I do occasionally see calls failing to process as the remote gateway fails the call with a "400 Bad From header". Inspecting the A-leg INVITE and the B-leg INVITE after updating the pseudovariables, I see the following: A-leg INVITE: INVITE sip:15551112222@example.com SIP/2.0 Via: SIP/2.0/UDP 79..xx.xx.xx:61379;rport;branch=z9hG4bKPj2b8935f4460447538d0176dcfb5c74a1 Max-Forwards: 70 From: sip:12223334444@example.com;tag=dff3c585a6154f23898e1121918f1752 To: sip:15551112222@example.com Contact: <sip:12223334444@79..xx.xx.xx:61379;ob> Call-ID: d793331e066f47bdafc0ad957cb506cc CSeq: 30770 INVITE Allow: PRACK, INVITE, ACK, BYE, CANCEL, UPDATE, INFO, SUBSCRIBE, NOTIFY, REFER, MESSAGE, OPTIONS Supported: replaces, 100rel, timer, norefersub Session-Expires: 1800 Min-SE: 90 Proxy-Authorization: Digest username="12223334444", realm="example.com", nonce="ZhUw02YVL6cdi51KMymTxGpzCZCZhd8G", [uri="sip:15551112222@example.com](mailto:uri=)", response="3a25b4ea0b1154e31caee1184a92f12b" Content-Type: application/sdp Content-Length: 627 v=0 o=- 3921660487 3921660487 IN IP4 79..xx.xx.xx s=pjmedia b=AS:84 t=0 0 a=X-nat:0 m=audio 4006 RTP/AVP 96 97 98 99 3 0 8 9 120 121 122 c=IN IP4 79..xx.xx.xx b=TIAS:64000 a=rtcp:4007 IN IP4 79..xx.xx.xx a=sendrecv a=rtpmap:96 speex/16000 a=rtpmap:97 speex/8000 a=rtpmap:98 speex/32000 a=rtpmap:99 iLBC/8000 a=fmtp:99 mode=30 a=rtpmap:3 GSM/8000 a=rtpmap:0 PCMU/8000 a=rtpmap:8 PCMA/8000 a=rtpmap:9 G722/8000 a=rtpmap:120 telephone-event/16000 a=fmtp:120 0-16 a=rtpmap:121 telephone-event/8000 a=fmtp:121 0-16 a=rtpmap:122 telephone-event/32000 a=fmtp:122 0-16 a=ssrc:63772004 cname:3ff849bd611036a7 ---------------------------------- B-leg INVITE: INVITE sip:15551112222@togateway.com SIP/2.0 Record-Route: <sip:10.64.54.207;lr;ftag=dff3c585a6154f23898e1121918f1752;did=e21.65c1> Via: SIP/2.0/UDP 10.64.54.207:5060;branch=z9hG4bK919d.5ca83e030c0879093169546cd80591a6.0 Via: SIP/2.0/UDP 79..xx.xx.xx:61379;received=79..xx.xx.xx;rport=61379;branch=z9hG4bKPj2b8935f4460447538d0176dcfb5c74a1 Max-Forwards: 15 From: sip:12125557777@example.com"Updated Name" ;tag=dff3c585a6154f23898e1121918f1752 To: sip:15551112222@togateway.com Contact: <sip:12125557777@79..xx.xx.xx:61379;ob> Call-ID: d793331e066f47bdafc0ad957cb506cc CSeq: 30770 INVITE Allow: PRACK, INVITE, ACK, BYE, CANCEL, UPDATE, INFO, SUBSCRIBE, NOTIFY, REFER, MESSAGE, OPTIONS Supported: replaces, 100rel, timer, norefersub Session-Expires: 1800 Min-SE: 90 Content-Type: application/sdp Content-Length: 609 v=0 o=- 3921660487 3921660487 IN IP4 10.64.54.207 s=pjmedia b=AS:84 t=0 0 a=X-nat:0 m=audio 18400 RTP/AVP 96 97 98 99 3 0 8 9 120 121 122 c=IN IP4 10.64.54.207 b=TIAS:64000 a=ssrc:63772004 cname:3ff849bd611036a7 a=rtpmap:96 speex/16000 a=rtpmap:97 speex/8000 a=rtpmap:98 speex/32000 a=rtpmap:99 iLBC/8000 a=fmtp:99 mode=30 a=rtpmap:3 GSM/8000 a=rtpmap:0 PCMU/8000 a=rtpmap:8 PCMA/8000 a=rtpmap:9 G722/8000 a=rtpmap:120 telephone-event/16000 a=fmtp:120 0-16 a=rtpmap:121 telephone-event/8000 a=fmtp:121 0-16 a=rtpmap:122 telephone-event/32000 a=fmtp:122 0-16 a=sendrecv a=rtcp:18401 Note that I've updated the following on the B-leg: $fn = "Updated Name" // originally nothing $fu = sip:12125557777@example.com // originally sip:12223334444@example.com $tu = sip:15551112222@togateway.com // originally sip:15551112222@example.com While the from uri, and to uri do get updated, the from name is injected in the wrong place of the from header. This only seems to happen when the A-leg is missing the "<" and ">" characters enclosing the from headers. Should I not be updating the pseudo variables in this manner to update the from name, to uri and from uri; is there another way to update these attributes of the header without malforming it? Thank you.

3 months, 2 weeks

making HTTP requests in stateless redirects

by Sergio Charrua

Hi all! For testing purposes, while I am waiting for the ST/SH REST API to be available from other teams, I developed a small python REST API that returns a mockup of a JSON object with some of the required values. The kamailio script, completely stateless as I do not need to keep track of the sessions, iterates through one of the JSON branches and adds the destination URLs to the Contact header and replies a SIP 300 Multiple Choices. This works: the UAC does receive the SIP response with the Contacts , but it also receives a SIP 500 error message right after, and I can't figure out why. And i bet this is simple to solve.... Any clue? I'm aware I'm not processing ACK messages, but the sl_send_reply 403 should do the trick right? ... at least while testing.... Also, as this is a stateless script, is there another way of using async http or making http requests to a REST API without having to use TM Module? Thanks in advance. The kamailio script is has follows: #!KAMAILIO > /* add API http timeout */ > #!define HTTP_API_TIMEOUT 5000 > #!define HTTP_API_ROUTING_ENDPOINT "http://some_python_rest_api/get_route" > ### LOG Levels: 3=DBG, 2=INFO, 1=NOTICE, 0=WARN, -1=ERR > debug=4 > log_stderror=no > memdbg=5 > memlog=5 > log_facility=LOG_LOCAL0 > log_prefix="{$mt $hdr(CSeq) $ci} " > /* number of SIP routing processes */ > children=2 > /* set paths to location of modules */ > loadmodule "tm.so" > loadmodule "jsonrpcs.so" > loadmodule "kex.so" > loadmodule "corex.so" > loadmodule "sl.so" > loadmodule "db_mysql.so" > loadmodule "rr.so" > loadmodule "pv.so" > loadmodule "maxfwd.so" > loadmodule "ipops.so" > loadmodule "textops.so" > loadmodule "siputils.so" > loadmodule "xlog.so" > loadmodule "sanity.so" > loadmodule "ctl.so" > loadmodule "cfg_rpc.so" > loadmodule "uac.so" > loadmodule "counters.so" > loadmodule "http_async_client.so" > loadmodule "jansson.so" > loadmodule "usrloc.so" > /* listen addresses */ > listen=udp:10.20.0.2:5060 > listen=udp:10.20.0.2:5062 > advertised_address="10.20.0.2"; > # ----- http_async_client params ----- > modparam("http_async_client", "workers", HTTP_ASYNC_CLIENT_WORKERS) > modparam("http_async_client", "connection_timeout", 2000) > request_route { > #route(HANDLE_DMQ); > route(HANDLE_OPTIONS); > if (is_method("INVITE")) > { > xlog("L_INFO","MAIN - calling TO_CARRIER"); > route(TO_CARRIER); > exit; > } > else{ > sl_send_reply("401","UNAUTHORIZED"); > } > } > route[TO_CARRIER]{ > xlog("L_INFO","TO_CARRIER - calling RELAY_API"); > route(RELAY_API); #Route relay > xlog("L_INFO","TO_CARRIER - return"); > return; > } > # Relay request using the API (response) > route[RELAY_API_RESPONSE] { > xlog("L_INFO","RELAY_API_RESPONSE - got response from REST API"); > if ($http_ok==1 && $http_rs==200) > { > xlog("L_INFO","RELAY_API_RESPONSE - HTTP RESPONSE: > $http_rb\n"); > if (jansson_get("json", $http_rb, "$var(json)")) { > xlog("L_INFO","RELAY_API_RESPONSE - JSON = > $var(json)"); > $var(count) = 0; > jansson_array_size("routes", $var(json), > "$var(size)"); > xlog("L_INFO","RELAY_API_RESPONSE - > jansson_array_size"); > >> >> while ( $var(count) < $var(size) ){ > > >> jansson_get("routes[$var(count)].headers.to.uri", $var(rtjson), "$var(v)"); > > xlog("L_INFO","JSON - routes[$var(count)] >> - $var(v)"); > > #$(avp(mycontacts)[$var(count)]) = >> $avp(mycontacts) + $var(v) + "\r\n"; > > $avp(mycontacts) = $avp(mycontacts) + >> $var(v) + ";"; > > > *append_to_reply("Contact: <" + $var(v) >> +">"+ "\r\n"); /* ---- IS THERE A BETTER ?? ..... */* > > > $var(count) = $var(count) + 1; > > } > > > xlog("L_INFO","RELAY_API_RESPONSE - RELAY"); > xlog("L_INFO","MAIN - calling REPLY_302"); > route(REPLY_302); > return; > } > } > send_reply(500, "API Not Available - http response = $http_rs > $http_ok"); > exit; > } > route[RELAY_API] { xlog("L_INFO","RELAY_API - from_ip $si:$sp from_number $fU > to_number $ru"); > $http_req(all) = $null; > $http_req(suspend) = 1; > $http_req(timeout) = HTTP_API_TIMEOUT; > $http_req(method) = "POST"; > $http_req(hdr) = "Content-Type: application/json"; > jansson_set("string","from_ip",$si, "$var(http_routing_query)"); > jansson_set("string","from_port",$sp, "$var(http_routing_query)"); > jansson_set("string","from_number",$fU, > "$var(http_routing_query)"); > jansson_set("string","to_number",$ru , "$var(http_routing_query)"); > > xlog("L_INFO","RELAY_API - API ASYNC ROUTING REQUEST: > $var(http_routing_query)\n"); > $http_req(body) = $var(http_routing_query); > t_newtran(); > http_async_query(HTTP_API_ROUTING_ENDPOINT, "RELAY_API_RESPONSE"); > xlog("L_INFO","RELAY_API - Waiting for Response"); > } > route[REPLY_302] { > # Sends a 300 Multiple Choices back to the proxy that requested the > routing lookup > xlog("L_INFO","REPLY_302 - send reply"); > sl_send_reply("300", "Multiple Choices"); > xlog("L_INFO","REPLY_302 - exit"); > exit; > } > route[HANDLE_OPTIONS]{ > if(is_method("OPTIONS")) > { > sl_send_reply(200, "OK"); > exit; > } > if ($fU=="ping") > { > sl_send_reply("200","OK"); > exit; > } > } SNGrep output: 1 - INVITE from UAC to Kamailio INVITE sip:918228990@10.20.0.2 SIP/2.0 > Via: SIP/2.0/UDP 10.20.0.1:5063;branch=z9hG4bK58aa83f4 > Max-Forwards: 70 > From: "Anonymous" <sip:anonymous@anonymous.invalid:5063>;tag=as192b8891 > To: <sip:918228990@10.20.0.2> > Contact: <sip:anonymous@10.20.0.1:5063> > Call-ID: 531668b959674f9f667f1c923d1d6c94@10.20.0.1:5063 > CSeq: 102 INVITE > User-Agent: SIPp > Date: Mon, 08 Apr 2024 15:09:51 GMT > Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, > PUBLISH, MESSAGE > Supported: replaces, timer > Content-Type: application/sdp > Content-Length: 270 > v=0 > o=root 2021555890 2021555890 IN IP4 10.20.0.1 > s=SIPp > c=IN IP4 10.20.0.1 > t=0 0 > m=audio 18422 RTP/AVP 8 0 101 > a=rtpmap:8 PCMA/8000 > a=rtpmap:0 PCMU/8000 > a=rtpmap:101 telephone-event/8000 > a=fmtp:101 0-16 > a=ptime:20 > a=maxptime:150 > a=sendrecv 2 - Reply from Kamailio to UAC SIP/2.0 100 trying -- your call is important to us > Via: SIP/2.0/UDP 10.20.0.1:5063;branch=z9hG4bK58aa83f4 > From: "Anonymous" <sip:anonymous@anonymous.invalid:5063>;tag=as192b8891 > To: <sip:918228990@10.20.0.2> > Call-ID: 531668b959674f9f667f1c923d1d6c94@10.20.0.1:5063 > CSeq: 102 INVITE > Server: kamailio (5.7.4 (x86_64/linux)) > Content-Length: 0 3 - SIP 300 Multiple Choices from Kamailio to UAC SIP/2.0 300 Multiple Choices > Via: SIP/2.0/UDP 10.20.0.1:5063;branch=z9hG4bK58aa83f4 > From: "Anonymous" <sip:anonymous@anonymous.invalid:5063>;tag=as192b8891 > To: <sip:918228990@10.20.0.2 > >;tag=57c593265e21c2b70aea50cb414df9cd.32679ccd > Call-ID: 531668b959674f9f667f1c923d1d6c94@10.20.0.1:5063 > CSeq: 102 INVITE > Contact: <sip:sip:918228990@10.20.0.2@sip.domain.io> > Contact: <sip:+351sip:918228990@10.20.0.2@10.20.0.3> > Server: kamailio (5.7.4 (x86_64/linux)) > Content-Length: 0 4 - SIP 500 from Kamailio to UAC SIP/2.0 500 I'm terribly sorry, server error occurred (1/TM) > Via: SIP/2.0/UDP 10.20.0.1:5063;branch=z9hG4bK58aa83f4 > From: "Anonymous" <sip:anonymous@anonymous.invalid:5063>;tag=as192b8891 > To: <sip:918228990@10.20.0.2 > >;tag=4eb2322b7d2b68e6fc3168f503344c21-32679ccd > Call-ID: 531668b959674f9f667f1c923d1d6c94@10.20.0.1:5063 > CSeq: 102 INVITE > Server: kamailio (5.7.4 (x86_64/linux)) > Content-Length: 0 5 - ACK from UAC to Kamailio ACK sip:918228990@10.20.0.2 SIP/2.0 > Via: SIP/2.0/UDP 10.20.0.1:5063;branch=z9hG4bK58aa83f4 > Max-Forwards: 70 > From: "Anonymous" <sip:anonymous@anonymous.invalid:5063>;tag=as192b8891 > To: <sip:918228990@10.20.0.2 > >;tag=57c593265e21c2b70aea50cb414df9cd.32679ccd > Contact: <sip:anonymous@10.20.0.1:5063> > Call-ID: 531668b959674f9f667f1c923d1d6c94@10.20.0.1:5063 > CSeq: 102 ACK > User-Agent: SIPp > Content-Length: 0 and continues with ACK and repeating SIP 500 above.... *Sérgio Charrua* .

3 months, 2 weeks

Kamailio Admin Book email

by sadik.oualla.mohamed＠gmail.com

Hello, Last week, I submitted a request on the Asipto website to purchase the Kamailio Admin Book and received an automatic confirmation email. However, I have not received any further instructions on how to complete the purchase. I replied to the automatic email to follow up, but still, there has been no response. I need to get the book as soon as possible. Please note, I am writing from a different email address than the one I used to make the request on Asipto's site. If there are any issues with their contact email, or if further verification is needed, please let me know how to proceed securely without sharing personal details publicly on this list. Regards, Mohamed.

3 months, 2 weeks

customizing the ds_ping_interval dispatcher parameter for destination

by Giuseppe Pandolfi

Hi, I have one question about dispatcher module in kamailio V.5.3.1. Why the ds_ping_interval parameter is only global value? Is it possible introduce the customization value for single destination? Customization from destination is already possible for ds_ping_from parameter using special attributes in destination list file or db table, is it possible introduce the same management for ds_ping_interval? Thanks, Giuseppe ________________________________ NOTA BENE: Le informazioni contenute nel presente messaggio, compresi gli eventuali allegati, sono strettamente confidenziali ed indirizzate unicamente al destinatario indicato. Qualora non foste il destinatario Vi invitiamo a cancellare il messaggio, ed ogni eventuale documento allegato, non divulgare il contenuto a terze persone ed a volerci avvisare a mezzo posta elettronica. Grazie. A TLC S.r.l. tratta i vostri dati personali nel rispetto della normativa vigente in materia di Privacy (D.Lgs.196/2003 modificato dal D.Lgs.101/2018 e GDPR Regolamento UE n.679/2016). Per consultare l’Informativa completa la invitiamo a visitare il nostro sito web “www.aethra.com<http://www.aethra.com/>” PLEASE NOTE: This message and any attachments are confidential and may contain privileged information. If you are not the intended recipient, you are kindly requested to cancel it, not to disclose the contents to any other person and to notify the sender immediately by return e-mail. Thanks. A TLC S.r.l. collects your personal data in compliance with applicable data protection laws (D.Lgs. 196/2003 amended by Legislative Decree 101/018 and GDPR EU Regulation n. 679/2016). Please visit our website ”www.aethra.com<http://www.aethra.com>” to consult the complete Policy.

3 months, 2 weeks

RFC: uptime metric for xhttp_prom module

by Ovidiu Sas

Hello all, The xhttp_module can export all stats under "stats.get_statistics" RPC command. I was thinking of adding an optional "uptime" stat that will return the kamailio server uptime (like the "core.uptime" RPC command). This will make it easier to add an uptime panel in grafana. The new stat would be controlled by a module parameter (by default disabled). Something like: modparam("xhttp_prom", "xhttp_prom_uptime_stat" 1) And this will generate something like: kam_uptime 671 1712249054631 This can be already implemented in the script using the "prom_gauge_set()" and retrieving the uptime via "jsonrpc_exec()", but it would be nicer and faster to implement it in the module itself. Comments? -ovidiu

3 months, 3 weeks

Kamailio Visions 2030 for Appalachia

by Alex Balashov

For immediate release: HAZARD, Kentucky (1 April 2024)--Evariste Systems LLC, Georgia-based veteran brokers of international charity partnerships, are pleased to announce the conclusion of lengthy trilateral negotiations among Taylor Swift, the Public Investment Fund (the sovereign wealth fund of the Kingdom of Saudi Arabia), and the Kamailio open-source community to bring Kamailio to underserved areas of the US Appalachia region. In a concert in Lexington, Kentucky last Sunday evening, and in her signature style of mystical "reveals" through equivocal song lyrics, Swift auspiciously inaugurated to her Swifties, as die-hard fans of the pop star are known, the beginning of Kamailio Visions 2030. (Editorial note: Swift's agent has threatened copyright litigation in the event that our press agency were to reproduce her meaning-rich lyrics directly, driven by the contention that fair use considerations do not apply to lyrics so "deep" as Swift's. At press time, the matter is being reviewed by our counsel.) Alex Balashov, principal of Evariste, praised Kamailio Visions 2030 as a continuation of Swift's long-standing commitment to forward thinking and innovation: "Taylor has been the driving force behind the use of sustainable, plant-based materials in her 'merch. Today, aided by the internationalisation of Saudi capital, she is helping to bring that same kind of ethical prosperity to Eastern Kentucky, West Virginia and the wider Appalachian coal country." Continued Balashov: "Between Alan Maimon and J.D. Vance, and the revelations of the Purdue Pharma litigation, it's fair to say that the plight of Appalachia, with its high structural unemployment, declining economic base, and the ravages of the opioid epidemic and deaths of despair, has been exposed to a broader audience than ever before. And with that knowledge comes responsibility, because we live with that knowledge now, and we can no longer turn a blind eye. The SIP and VoIP industries have always been a force of conscientious capitalism, and Kamailio a beacon of rectitude in a jaded, amoral, cynical world. A world in which Appalachian children are denied the SIP proxy is not a just world, and we cannot any longer live in such a world." Fred Posner, a deputy Evariste negotiator who was said to have thrived in the pressure of high-stakes negotiations with PIF governor Yasir Al-Rumayyan over the exact implementational modalities of the deal, reviewed the high notes of the landmark economic development accord: "It was a good start to defund the police. But with the unique social challenges of Appalachia, what every struggling family in the ruins of coal country really needs is access to clean, ethically sourced, fair-trade SIP proxies. That is why I am uplifted to say that we will be dropping, through a coordinated, large-scale airlift operation, a Raspberry Pi with Kamailio pre-installed, to every household with an income at or below 250% of the Federal Poverty Level (FPL) in the Appalachian region. The Pi chassis will be dye-free, BPA-free, and will be held together with a plant-based, biodegradable, non-toxic glue that does not produce intoxicating effects when sniffed. By 2030, every child alive in Appalachia today will have had several years to benefit from the power of a miniaturised SIP proxy appliance, and that is why we are calling it Kamailio Visions 2030." When pressed by us, Balashov noted that the prosocial objectives and economic development potential of Kamailio Visions 2030 has drawn scepticism from some quarters. "These are those people who think that Rasperry Pi devices preloaded with Kamailio are not what Appalachia most needs today. Those people would be wrong. As any metaphysicist can tell you, causes do not necessarily resemble their effects." "Taylor and her people know that Kamailio Visions 2030 draws on a long history of highly effective technological and app-based interventions in economically underprivileged areas, such as Nicholas Negroponte's One Laptop per Child (OLPC) scheme, and the famous carpet-bombing of Eritrea with second-generation iPads by Selena Gomez. All of this had tremendous results." "Salutary results", added a representative of the PIF. Balashov pointed us to the foundational problem statement of Kamailio Visions 2030, which cited the concept of "Technik", as developed in "Hybrid Reality", a technocratic manifesto (in e-book form) by much-loved TED visionaries Parag and Ayesha Khanna. There, the authors declared: "Good Technik requires a combination of the attributes that deliver high human development, economic growth, political inclusiveness, and technology preparedness.” "In short", said Balashov, "Taylor, with some help from the efficient deployment of Saudi capital, will bring good technik to Appalachia. The tide of technik lifts all ships." -- Alex Balashov Principal Consultant Evariste Systems LLC Web: https://evaristesys.com Tel: +1-706-510-6800

3 months, 3 weeks

low performance with no apparent reason

by Sergio Charrua

Hi all! I have been doing some performance tests with Kamailio 5.7.4 and SIPp. The infrastructure is as follows:3 VMs running on VMWare ESXi running: UAC on 10.20.0.1 with SIPP-> Kamailio on 10.20.0.5 -> UAS on 10.20.0.3 The Kamailio VM has 6 dedicated vCPU of type Intel(R) Xeon(R) Silver 4216 CPU @ 2.10GHz and, 2 NICs and 4Gb RAM and MariaDB 10.6 as DB Backend., all running on a HP G380 host with a gazillion CPUs and a googol disk space! I currently have 3 scripts: - script #1 stateful with RTJson and simulating requests to routing engine and accounting - script #2 stateful but with just a simple routing to UAS, no rules, no DB, - script #3 stateless with a forward to UAS With script #3 I can go up to 2000CPS without issues with CPU at 37%! Above that value, I get retransmissions everywhere. On both scripts #1 and #2, the limit is 330CPS max after which I get a lot of retransmissions, while CPU/Core usage on Kamailio server stays below 10%. So I do not expect this to be a CPU issue. I could not understand why such (low) results, so I followed this article found at https://www.kamailio.org/docs/openser-performance-tests/#tm-tests-c <https://www.kamailio.org/docs/openser-performance-tests/#tm-tests-c> and created exact same scenarios, with kamailio script and SIPP templates available on the article, hoping for better results. But I get the same results: between 300 and 330CPS which is far, very far from the 7000CPS found in the article! I understand that I'm using VMs and probably the tests made for the article, which is pretty old already, were made on physical servers. Still, I would not expect 95% of lower performance! Any clue what could be the issue? I suspect NICs, but.... Any tips anyone could share? Thanks in advance! *Sérgio Charrua*

3 months, 3 weeks

Statistics for all generated

by Alfredo Román Domínguez

I am using Kamailio versions 5.5.7 and 5.8.0 as a stateful proxy (with tm module) and I want to have metrics for all the SIP messages received and sent. I am using the statistics module for counting messages. I have in configuration file the following routes to capture events and count them: onsend_route, onreply_route and event ( corex:reply-out, tn:local_response, sl:local-response, tm:local-request, sl:filtered-ack and network:msg) I have found the following problems that I need some hints how to solve them: 1) When a response is received to a request, I can count the response received in the reply_route but I don't find a way that works to count the reply being forwarded to the other side. onsend_route works fine for requests being forwarded. Is there any event_route or any trick that can be used to count the reply being forwarded similar to the onsend_route for requests? 2) When Kamailio receives a CANCEL it generates and sends automatically the 200 OK for the CANCEL and a 487 for the INVITE which started that dialog which is being cancelled, but I don't find a way that works to count those two responses Kamailio generates. 3) After having cancelled a dialog on one direction due to receipt of a CANCEL, kamailio generates local requests on the other direction, a CANCEL and an ACK also when it receives a 487 for the INVITE being cancelled. I don't find the way to count those. onsend_route does not work for locally generated CANCEL and ACK requests and the event_route[tm:local-request] only works for requests created outside of the tm module but not those created by the tm module itself (the CANCEL and the ACKs) since the tm module is not using its own function t_uac_prepare to create those requests (that function is the one that calls the event_route). Is there any statistic generated by the tm module or elsewhere or any other trick so I can count those requests? 4) When Kamailio generates retransmissions how can I count those? onsend_route, onreply_route and event ( corex:reply-out, tn:local_response, sl:local-response) doesn't work for retransmissions. Are there statistics generated somewhere in the tm module for retransmissions? Is there any other way to count those. -- El contenido de este mensaje puede contener información confidencial sometida a secreto profesional. Si usted ha recibido este correo por error, no está permitida su distribución. Por favor elimine cualquier copia, archivo adjunto e infórmenos por esta vía. Los datos personales contenidos en este correo y que han sido facilitados por usted o provienen de fuentes de acceso público serán utilizados por Future Space, S.A., para gestionar nuestra relación contractual o pre-contractual, resolver su solicitud y mantenerle informado sobre los productos o servicios solicitados o similares. Se conservarán mientras exista un interés mutuo para ello, no se oponga al tratamiento o solicite su supresión. Los datos no serán comunicados a terceros, salvo obligación legal. Puede ejercitar sus derechos de acceso, rectificación, supresión, limitación del tratamiento, portabilidad de los datos y oposición mediante escrito dirigido a Future Space, S.A. Avenida de Tenerife 2, Edificio 2, Planta 1ª, 28703 San Sebastián de los Reyes, Madrid o mediante correo electrónico a dpo(a)futurespace.com <mailto:dpo@futurespace.com>. Si consideras que se han infringido tus derechos puedes presentar una reclamación ante la www.agpd.es <http://www.agpd.es>. The contents of this electronic mail may be confidential or privileged. If you have received this message by mistake, please do not send it to anyone. We ask you to delete any existing copies, attached files and to notify us accordingly. The personal data provided or obtained from publicly accessible resources will be processed by Future Space, S.A. in order to manage our contractual or pre-contractual relationship, solve your request and keep you informed about activities or products requested by you or similar. Personal data will be stored while a mutual interest exist or either erasure or objection to process them is requested. Data will not be disclosed to third parties unless there is a legal obligation to do so. You have the rights to access, rectify, erasure, restriction of processing, data portability and oppose any processing of your personal data held by Future Space, S.A. To make effective use of your rights, please contact us at Future Space, S.A. Avenida de Tenerife 2, Edificio 2, Planta 1ª, 28703 San Sebastián de los Reyes, Madrid or by email at dpo(a)futurespace.com <mailto:dpo@futurespace.com>. If you consider processing of your personal data infringes data protection regulations you can file a claim with www.agpd.es <http://www.agpd.es>

3 months, 3 weeks

TLS module doesn't support TLSV1

by o.atef＠fiberme.com

Hello Brothers, I've installed kamailio throw "apt install" on Debian and it's installed version: kamailio 5.6.3 (x86_64/linux). Now I've a big problem that kamailio cannot running with TLSv1 and it has to be TLSv1.2+ as tls.cfg doc said: # We do not enable anything else than TLSv1.2+ # over the public internet. Clients do not have # to present client certificates by default. How could I avoid this restriction please to enable TLSv1? Thank you,

3 months, 3 weeks

Kamailio v5.8.1 Released

by Daniel-Constantin Mierla

Hello, Kamailio SIP Server v5.8.1 stable release is out. This is a maintenance release of the latest stable branch, 5.8, that includes fixes since the release of v5.8.0. There is no change to database schema or configuration language structure that you have to do on previous installations of v5.8.x. Deployments running previous v5.8.x versions are strongly recommended to be upgraded to v5.8.1. For more details about version 5.8.1 (including links and guidelines to download the tarball or from GIT repository), visit: * https://www.kamailio.org/w/2024/04/kamailio-v5-8-1-released/ RPM, Debian/Ubuntu packages will be available soon as well. Many thanks to all contributing and using Kamailio! Cheers, Daniel -- Daniel-Constantin Mierla (@ asipto.com) twitter.com/miconda -- linkedin.com/in/miconda Kamailio Consultancy, Training and Development Services -- asipto.com Kamailio World Conference, April 18-19, 2024, Berlin -- kamailioworld.com

3 months, 3 weeks

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