Hi community,
I am preparing a setup of Kamailio with radius accounting on a docker-compose environment. When configuring the acc_radius module I had to navigate through some old doc by Daniel and inspecting the code itself. The thing is that it seems working, but not. And, yes, I already trying without docker :)
Context: two containers, host newtork, to keep it simple
- one with kamailio + modules (acc, acc_radius with rad_cli) + radius client configuration
- another with freeradius + radius client configuration.
I ensure that all data correspond and radius config is fine and spin them up. Run some radius commands to test and let's try some accounting...
Executing a failed call and triggering the account flag method, I receive an opaque -1 error from the module:
```
kamailio-1 | 1(20) INFO: {1 22 INVITE yutncivdtflvzga@PT-96} <script>: Initial requests
kamailio-1 | 1(20) INFO: {1 22 INVITE yutncivdtflvzga@PT-96} <script>: FLAG FLT_ACC set
kamailio-1 | 1(20) NOTICE: {1 22 INVITE yutncivdtflvzga@PT-96} acc [acc.c:286]: acc_log_request(): ACC: call missed: timestamp=1709746392;method=INVITE;from_tag=wvaqi;to_tag=1a86669fc745788378faa461e7993953-78550000;call_id=yutncivdtflvzga@PT-96;code=404;reason=Not Found;src_user=1000;src_domain=kamailio-local;src_ip=172.20.0.1;dst_ouser=1001;dst_user=1001;dst_domain=kamailio-local
kamailio-1 | 1(20) ERROR: {1 22 INVITE yutncivdtflvzga@PT-96} acc_radius [acc_radius_mod.c:497]: acc_radius_send_request(): Radius accounting - ERROR - result: -1
```
Log accounting is working ok, but radius accounting not. Time for troubleshooting.
I tried to enable client debugging, but the module does not respond. So I modify the source directly... tested with `radclient` , `radtest`, `radsniff`... all seems to work when trying manually... I also used an internal radcli fuction `rc_check()` and it works. Meanwhile, I was unable to make it work with the module and the radcli library.
So another log output using internal functions to debug the configuration:
```
kamailio-1 | 0(18) INFO: acc_radius [acc_radius_mod.c:312]: check_cfg(): Clave: nas-identifier, Valor: radius-wac
kamailio-1 | 0(18) INFO: acc_radius [acc_radius_mod.c:312]: check_cfg(): Clave: authserver, Valor: radius
kamailio-1 | 0(18) INFO: acc_radius [acc_radius_mod.c:312]: check_cfg(): Clave: acctserver, Valor: radius
kamailio-1 | 0(18) INFO: acc_radius [acc_radius_mod.c:306]: check_cfg(): Clave: servers, Valor: /usr/local/etc/radcli/servers - OK file found
kamailio-1 | 0(18) INFO: acc_radius [acc_radius_mod.c:306]: check_cfg(): Clave: dictionary, Valor: /usr/local/etc/radcli/dictionary - OK file found
kamailio-1 | 0(18) INFO: acc_radius [acc_radius_mod.c:300]: check_cfg(): Clave: default_realm, Valor: -- not set --
kamailio-1 | 0(18) INFO: acc_radius [acc_radius_mod.c:312]: check_cfg(): Clave: radius_timeout, Valor: 10
kamailio-1 | 0(18) INFO: acc_radius [acc_radius_mod.c:312]: check_cfg(): Clave: radius_retries, Valor: 3
kamailio-1 | 0(18) INFO: acc_radius [acc_radius_mod.c:312]: check_cfg(): Clave: bindaddr, Valor: *
kamailio-1 | 0(18) INFO: acc_radius [acc_radius_mod.c:312]: check_cfg(): Clave: clientdebug, Valor: 1
kamailio-1 | 0(18) INFO: acc_radius [acc_radius_mod.c:369]: init_acc_rad(): RC_ACCT_INIT: rc_test_config looks good
kamailio-1 | 0(18) INFO: acc_radius [acc_radius_mod.c:375]: init_acc_rad(): RC_ACCT_INIT: Config applyed ok
```
The configuration seems ok, accepted by the library and seems to be applied properly, but when trying to parse its values... all seems like rubish...
```
kamailio-1 | 0(18) INFO: acc_radius [acc_radius_mod.c:401]: init_acc_rad(): RC_ACCT_INIT: Name: P�y:^
kamailio-1 | 0(18) INFO: acc_radius [acc_radius_mod.c:402]: init_acc_rad(): RC_ACCT_INIT: Max 1
kamailio-1 | 0(18) INFO: acc_radius [acc_radius_mod.c:403]: init_acc_rad(): RC_ACCT_INIT: Port: 125489528
kamailio-1 | 0(18) INFO: acc_radius [acc_radius_mod.c:404]: init_acc_rad(): RC_ACCT_INIT: Secret:
kamailio-1 | 0(18) ERROR: acc_radius [acc_radius_mod.c:410]: init_acc_rad(): RC_CLIENTDEBUG: No clientdebug specified
```
I'm using `libradcli4 1.2.11-1+b2` for running on the container and `libradcli-dev 1.2.11-1build1` for compiling.
Open to hear ideas, somebody using it actively on latest 5.7 release?
Some updated documentation flying around?
I was thinking to open a GitHub issue to handle the documentation issue.
Thanks in advance!
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.
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.
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.
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
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
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*
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>
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,