Hello,
due to some changes from certain cloud infrastructure provider related to spam filtering with DMARC, we need to change the list manager "mailman" configuration for the following lists:
* sr-users
* sr-user-es
* sr-dev
* business
* sr-docs
* kamailio-announce
* the administrative mailing list
The change will impact the "From" that is displayed in your email program. Without that change large e-mail providers (Gmail, Microsoft O365) will reject messages from a sender with certain strict DMARC policy. This is already affecting several people on the lists (for example with GitHub notice mails), but over time the problem will certainly increase.
Regarding the technical change:
We will munge the From: header so it doesn't contain the domain that triggers the DMARC rejection. Essentially, the Mailman list takes ownership of the message and injects its own address into the From: header. This can affect reply-to-sender, although we add the original From: address in the Reply-To: header (or sometimes the Cc: header) to reduce the impact of this. We plan to do this for all emails unconditionally, regardless of their sender DMARC policy, to have an identical behaviour for all users. Please refer to this [1] page for more details. For a general description of DMARC refer to this page [2].
This change should have not a big impact for you, but some users might need to adapt some mail filters. Therefore, we would like to gather feedback on that change from you. We expect that the most visible change is that It will be not possible anymore to just reply by e-mail to mails from GitHub and have them "automatically" added to the discussed issue. This feature was so far used rarely and only from a few people.
We plan to implement this change by the end of this week, when its done it will be also shortly announced.
Best regards,
Henning Westerholt
[1] https://wiki.list.org/DEV/DMARC
[2] https://dmarc.org/overview/
--
Henning Westerholt - https://skalatan.de/blog/
Kamailio services - https://gilawa.com<https://gilawa.com/>
Hi Team
Could anyone point me in the direction where I could find out more
what's going wrong and what could be the cause of messages like:
Sep 22 07:32:29 dev-core02 kamailio[915066]: CRITICAL: dialog [dlg_timer.c:129]: insert_dlg_timer(): Trying to insert a bogus dlg tl=0x7f9617d967b0 tl->next=0x7f9618e11198 tl->prev=0x7f9617e20548
Sep 22 07:32:29 dev-core02 kamailio[915066]: CRITICAL: dialog [dlg_dmq.c:314]: dlg_dmq_handle_msg(): Unable to insert dlg timer 0x7f9617d96750 [1598:12168]
Are the numbers in brackets [hash_id:hash_entry] ?
--
Mit freundlichen Grüssen
-Benoît Panizzon- @ HomeOffice und normal erreichbar
--
I m p r o W a r e A G - Leiter Commerce Kunden
______________________________________________________
Zurlindenstrasse 29 Tel +41 61 826 93 00
CH-4133 Pratteln Fax +41 61 826 93 01
Schweiz Web http://www.imp.ch
______________________________________________________
Hi Team
I'm still hunting dialog errors which cause my dialog counters to
divert and stick around, basically exploding in my face now and then. I
suppose they are DMQ related (maybe packet loss, maybe retransmissions,
maybe generic overloading of the virtualized kamailio instances)
causing issues with inserting dialog timers on the peer etc.
So for the moment I'm running only one instance, no DMQ peer.
What I still occasionally see are messages:
INVITE]dialog [dlg_hash.c:1182]: next_state_dlg(): bogus event 2 in
state 3 for dlg 0x7ff906294be8 [2482:872] with clid 'A8459C74@7f33ff47'
and tags '7f33ff47+1+7d820120+89494caf' '3904288054-1882699775'
I found an ancient post, confirming this to be an open bug in Kamailio
1.4 and race condition between the 200 OK reply to an INVITE and the ACK
confirming the 200 OK. Someone attempted to backport a fix for opensips
to kamailio.
Indeed, I see this message occur occasionally after managing the 200 OK
reply and routing the ACK.
Does anyone know, if this is still a open bug with Kamailio 5.5? Or
what else could be the cause of this message?
--
Mit freundlichen Grüssen
-Benoît Panizzon- @ HomeOffice und normal erreichbar
--
I m p r o W a r e A G - Leiter Commerce Kunden
______________________________________________________
Zurlindenstrasse 29 Tel +41 61 826 93 00
CH-4133 Pratteln Fax +41 61 826 93 01
Schweiz Web http://www.imp.ch
______________________________________________________
Hi
I need to take in a priority (from 0 to 100, 0 being highest prio) and
convert this into a Q value between 0 and 1.0
My idea was to simply do:
q_value = 1 - ($var(priority)/100)
However, it seems Kamailio only deals in integers in the config. A
Previous post suggested using xavp vars, but this ends up the same result.
Apart from doing a pseudo SQL query "SELECT 1 - (20/100)" is there any
way within the config I can do such maths?
Thanks
--
-Barry Flanagan
Hi all,
I'm attempting to use the uac module in KEMI (Python) to authenticate
outbound requests. When the downstream replies with a 401 the proxy
correctly re-sends the request with a Authorization header, but the 401 is
also relayed to the caller.
As far as I can tell I've converted the example to KEMI correctly, but no
matter what I try the 401 is still sent to the caller. Any ideas?
The config I'm using is below - The avps are set when the request is sent
so aren't visible here.
Thanks
def ksr_failure_manage(self, msg):
if self.ksr_route_natmanage(msg)==-255 : return 1
if KSR.tm.t_is_canceled()>0 :
return 1
if KSR.tm.t_check_status("401|407") >0 :
KSR.info(f"Got a 40X, should attempt authentication")
if KSR.uac.uac_auth()>0:
KSR.tm.t_relay()
KSR.info (f"Dropping further replies")
KSR.set_drop()
exit()
return 1
I need to manage failover in the connection between SCSCF and AS.
I need to understand how it is possible to configure Kamailio to handle the DNS SRV to manage failover for UAS transaction like REGISTER.
I see that it works for UAC transaction like INVITE, but I am not able to configure Kamailio to work for UAS transaction.
Thanks,
Massimo
________________________________
Massimo Dal Sasso
SW Developer
massimo.dalsasso(a)ext.athonet.com
[Athonet logo]<https://www.athonet.com/>
the mobile core that works for you
Athonet Italy
Via Cà del Luogo 6/8
36050 Bolzano Vicentino
Vicenza-Italy
+39 0444 750045
This email and any attachments are confidential and intended solely for the use of the intended recipient. If you are not the named addressee, please be aware that you shall not distribute, copy, use or disclose this email. If you have received this email by error, please notify us immediately and delete this email from your system. Email transmission cannot be guaranteed to be secured or error-free or not to contain viruses. Athonet S.r.l. processes any personal data exchanged in email correspondence in accordance with EU Reg. 679/2016 (GDPR) - you may find here the privacy policy with information on such processing and your rights. Any views or opinions presented in this email are solely those of the sender and do not necessarily represent those of Athonet S.r.l.
Hi all,
I'm using the acc module along with postgres to generate CDRs. For
connected calls the CDRs are created as expected, but in the scenario
where a lookup() fails and Kamailio sends a stateless 404 there's no
CDR logged.
I'm setting the FLT_ACCMISSED and FLT_ACCFAILED flags in the initial
request route, but perhaps I have a misunderstanding of how these
work?
Thanks
Matthew
Hi List
At the moment, we challenge every invite (and re-invite) to make sure
the customer is authenticated.
Now we have one kind of PBX, which never does not authenticate when we
challenge a Re-Invite.
According to the vendor of that PBX's RFC interpretation, answering a
challenge to a re-invite is optional. If that is ignored by the PBX,
then the existing established dialog shall not end.
Unfortunately this causes the session timer to run out.
I am therefore wondering, if there is a safe way not to challenge
re-invites.
A Re-Invite contains a To-Tag. So I could bypass authentication on
presence of a to-Tag. But then, how do I prevent a customer to just set
a spoofed To-Tag to circumvent authentication?
Is there a feasible way?
Mit freundlichen Grüssen
-Benoît Panizzon-
--
I m p r o W a r e A G - Leiter Commerce Kunden
______________________________________________________
Zurlindenstrasse 29 Tel +41 61 826 93 00
CH-4133 Pratteln Fax +41 61 826 93 01
Schweiz Web http://www.imp.ch
______________________________________________________
Should maxload work with all dispatcher algorithms?
I'm trying to add a test node to dispatcher.list with maxload=1 and it
is getting a lot more than one concurrent call. The test node is the
last one in the list.
16 sip:10.x.x.43:5070 0 0
duid=duid01;user=+10007787878;sockname=floating-internal-ip;maxload=0
16 sip:10.x.x.44:5070 0 0
duid=duid02;user=+10007787878;sockname=floating-internal-ip;maxload=0
16 sip:10.x.x.47:5070 0 0
duid=duid03;user=+10007787878;sockname=floating-internal-ip;maxload=0
16 sip:10.x.x.48:5070 0 0
duid=duid04;user=+10007787878;sockname=floating-internal-ip;maxload=0
16 sip:10.x.x.56:5070 0 0
duid=duid05;user=+10007787878;sockname=floating-internal-ip;maxload=0
16 sip:10.x.x.57:5070 0 0
duid=duid06;user=+10007787878;sockname=floating-internal-ip;maxload=0
16 sip:10.x.x.58:5070 0 0
duid=duid07;user=+10007787878;sockname=floating-internal-ip;maxload=0
16 sip:10.x.x.x:5070 0 0
duid=duid08;user=+10007787878;sockname=floating-internal-ip;maxload=0
16 sip:10.x.x.104:5060 0 0
duid=duid09;user=+10007787878;sockname=floating-internal-ip;maxload=1
On the understanding that you have checked the INVITE to 802 and it looks OK but not getting there then I would probably start digging on the networking side of it. You have said no Firewalls however there may be Security Groups and VPC bits going on in AWS.
It's hard to say as the level of detail is not in the ticket. Can 802 call 801? What happens if you log 802 into Kamailio 1 and 801 into Kamailio 2 and call either way.
Lewis
Mission Labs Limited is registered in England, company number 10040088. Trading Office: The Old Milk Depot, Bacup Rd, Rossendale, BB4 7FE. Registered office: The Scalpel, 18th Floor 52 Lime Street, London, EC3M 7AF. Email confidentiality notice: This message is private and confidential. If you have received this message in error, please notify us and remove it from your system. Please consider the environment before you print this email.
Hello All,
I have two kamailio servers and shared the database between two kamailio.
version: kamailio 5.5.6 (x86_64/linux) .
I have used AWS network load balancer. domain pointed to AWS network load balancer IP address,AWS Network Load Balancer (NLB) to distribute incoming requests to kamailio servers. I have two users in same domain(dev.domain.com).
1. 801(a)dev.domain.com --> Registered on kamailio 1
2. 802(a)dev.domain.com --> Registered on kamailio 2
Two call invites have been received, one for extension 801 and another for extension 802. These call invites will reach kamailio Server 1.
kamailio Lookup the users and send call invite to both the devices. 801 registered user will get a ring because it is registered from kamailio 1.
but 802 will not get a ring because it's register from kamailio 2.
I can able see kamailio send call invite to the both registered devices using sngrep. but it not reach to the 802 device. there i no firewalls so far.
also i have took 802 Registered device IP phone logs but there is no Call Invite reach to the 802 device.
I have also tried by using "dmq" and "dmq_usrloc" module but the same behavior.
what could be the reason? It will be appreciable if anyone help to resolve the issue.
Thank you in advance!
Pratik Svaliya.
Hi,
I am building a configuration script where for some traffic flows
parallel forking will be needed, and in this case I need to go beyond
the default max limit of the max amount of branches.
Apart from this specific case the traffic load that kamailio will need
to handle is very low, let's say just one second here and there with up
to 5 concurrent calls at most.
This limit is as far as I understand set here:
usr/local/src/kamailio-5.6/kamailio/src/core/config.h
And the default limit is:
#define MAX_BRANCHES_LIMIT 32 /*!< limit of maximum
number of branches per transaction */
Here are the questions I have related to this:
1) If I increase the value of this constant in config.h, how high is it
reasonable to set this value and still have a stable system?
2) If I increase MAX_BRANCHES_LIMIT beyond 32, are there also other
parameters that needs to be changed for the system to be able to cope,
and if so whichparameters?
Regards,
Lars
Hi Matteo
I have used http_async_client and http_client in both Native & KEMI to good affect for handling SUBSCRIBE & NOTIFY flows however did have a few issues with formatting which took a bit of work to get right.
Just to note, something you may want to test. Initially I set about my task using http client within Python (aiohttp and ayncio) and stepped in and out of it from various points in the logic depending on the config I was using at the time. Under load this proved to be a bottle neck and failed load testing. The best options under load were using http_async_client or http_client modules which offered significantly better performance.
In the end we took a different approach of using Kafka Module as that had even better performance but that was a decision taken our side not through any fault of the http_async_client or http_client modules
Lewis
Mission Labs Limited is registered in England, company number 10040088. Trading Office: The Old Milk Depot, Bacup Rd, Rossendale, BB4 7FE. Registered office: The Scalpel, 18th Floor 52 Lime Street, London, EC3M 7AF. Email confidentiality notice: This message is private and confidential. If you have received this message in error, please notify us and remove it from your system. Please consider the environment before you print this email.
Hi List
I'm attempting to add a header to a reply message on failure.
Situation:
Registrar => Core => (dispatcher list) => Various IC
I would like to know on the registrar, which of the dispatcher groups
failed.
What I attempted sofar:
failure_route[DISPATCH_FAILURE]
{
append_to_reply("X-RR: (append reply) Final Dispatch Failure $avp(dispgroup):$avp(trunkname)\r\n");
append_hf("X-RR: (append hf) Final Dispatch Failure $avp(dispgroup):$avp(trunkname)\r\n");
$avp(rstatus) = t_get_status_code();
$avp(rtext) = $T_rpl($rr);
$avp(rtext) = "REMOTE REPLY: " + $T_rpl($rr);
t_send_reply("$avp(rstatus)", "$avp(rtext)");
}
I only get status text is getting through to my reply. I would much prefer to add a header which I could then extract on the registrar. Am I missing something which could prevent addition of a header in a reply?
Mit freundlichen Grüssen
-Benoît Panizzon-
--
I m p r o W a r e A G - Leiter Commerce Kunden
______________________________________________________
Zurlindenstrasse 29 Tel +41 61 826 93 00
CH-4133 Pratteln Fax +41 61 826 93 01
Schweiz Web http://www.imp.ch
______________________________________________________
Hello all :)
I'm struggling to add two headers to an http client request, but cannot
find a proper way to do it.
The headers are Authorization and Content-Type.
The first try is with http_client module, beside undocumented, is possible
to add multiple headers separating them with "\r\n". What I see is the
correct Authorization header, and two Content-Type headers, one with my
content type the other with x-www-form-urlencoded, which no one sets ?
Second try is with http_async_client which supports multiple headers, but
since I'm calling it from an xhttp event route, there's no transaction and
request cannot be suspended, so I cannot get results before sending out
xhttp response...
Any hint?
br,
Mat
Hi List
I wonder if some of the devs could look at the dialog code and maybe
confirm my observation of this supposed Bug in Kamailio 5.6
Situation:
Two Kamailio, dialog counters synced via DMQ and each node using a
local DB as dialog backend.
Goal is to count channel usage per customer.
modparam("dialog", "db_mode", 1 )
modparam("dialog", "enable_dmq", 1)
modparam("dialog", "h_id_start", -1) # Use server_id
modparam("dialog", "h_id_step", 2)
modparam("dialog", "profiles_with_value", "custcallcounter")
If 'JohnDoe' is involved in a call, I do:
set_dlg_profile("custcallcounter","JohnDoe");
To check how many calls are busy by JohnDoe I do:
get_profile_size("custcallcounter","JohnDoe","$var(channel_use)");
Picture this situation:
JohnDoe is initiating a first call via Node1:
Node1 created the dialogue and variables, writes them to the database
and replicates the dialog vars to Node2 => IN MEMORY
Nothing about the running dialog is being written to the Database on
Node2, but get_profile_size returns the count on Node2.
So while the first call aka dialog is running via Node1, JohnDoe is
initiating a second call, this time via Node2.
Node2 creates the dialog and writes this to the database. Then the
profile with Name 'JohnDoe' is INCREASED on Node2.
This is when I suddenly find the dialog_vars on the Node2 database
containing information about the dialog started on Node1. So I guess
writing to a dialog counter triggers the dialog_vars being written to
the Database.
When JohnDoe is ending it's first call, then the dialog and dialog_vars
are cleaned out of the database on Node1, but NOT on Node2
What I fear happens next: They dialog_vars remaining on the Database of
Node 2 accumulate more and more, making the database slower. When a
call happens to re use the same hash id and entry, things start going
really badly.
Could I be right?
--
Mit freundlichen Grüssen
-Benoît Panizzon- @ HomeOffice und normal erreichbar
--
I m p r o W a r e A G - Leiter Commerce Kunden
______________________________________________________
Zurlindenstrasse 29 Tel +41 61 826 93 00
CH-4133 Pratteln Fax +41 61 826 93 01
Schweiz Web http://www.imp.ch
______________________________________________________
Hello,
Is it possible to put a kind of license for Kamailio, in a way that it works for 1 week for example, and after that it will not process new requests?
Regards,
The client uses the TLS protocol registered and TCP Connection established . There is a problem now, sending message KSR.uac.uac_req_send() from the kamilio server to client failed sometimes,and the error is as follows:
“2023-09-04T17:22:01.515763+08:00 (3429) ERROR: tm [../../core/forward.h:292]: msg_send_buffer(): tcp_send failed
2023-09-04T17:22:01.515763+08:00 (3429) ERROR: tm [uac.c:678]: send_prepared_request_impl(): Attempt to send to precreated request failed ”. meantime, the client sending message to Kamalio server succeded, and the register status and tcp connection is normal.
After 30s, obtained the $uac_req(evcode) from the event_route[uac:reply] is 408.After this error appears, all the messages sent to this client are 408.
"
2023-08-29T03:48:43.738152+08:00 (3349) NOTICE: <script>: ===uac reply received, callid = 0B6ECB534AE24281AED9BBBC56B140A6`yangwang2`1693252093, code is: 408
2023-08-29T03:48:43.738825+08:00 (3349) NOTICE: <script>: ===uac reply received, callid = 0B6ECB534AE24281AED9BBBC56B140A6`yangwang2`1693252093, code is: 408
"
But from other information, the TCP connection is normal. Because from Kamailio to querying this user's Location, it has not changed all day. The client sends messages is also normal. That is, the user's registration and sending messages can receive 200 OK.
We use netstat commands to view the user's TCP connection information on the client and server, and the connection status is also normal.The status of the corresponding port of the TCP connection is ESTABLISHED.
client:
netstat -ano | findstr 49957
"172. 17. 47.125:49957 XXX.96.XXX.XXX:5061 ESTABLISHED 10516"
server:
"tcp 0 0 10.11.xx.xx:5061 xxx.xxx.xxx.xxx:49957 ESTABLISHED 3467/kamailio"
This client is normal after logging in, and the problem that occurs after a period of use (maybe some hours), and once it occurs, it fails until the user creates a new connection and logs back in. Not all users will appear.
Why is this the case? The socket connection is fine, but uac_req_send () get an ERROR?
I found a problem from the log file. Is it caused by duplicate callids pushed to the same user at the same second?
Looking forward to your answer, thank you very much
Script information that may be required
kamailio.cfg : tm mode
# ----- tm params -----
# auto-discard branches from previous serial forking leg
modparam("tm", "failure_reply_mode", 3)
# default retransmission timeout: 30sec
modparam("tm", "fr_timer", 30000)
# default invite retransmission timeout after 1xx: 120sec
modparam("tm", "fr_inv_timer", 120000)
modparam("tm", "auto_inv_100", 1)
kamalio.lua uac_req_send()
" --uac_req_send
KSR.pv.sets("$uac_req(hdrs)", hdrs)
KSR.pv.sets("$uac_req(method)", "MESSAGE")
KSR.pv.sets("$uac_req(ruri)", "sip:" .. to .. "@" .. KAM_DOMAIN)
KSR.pv.sets("$uac_req(furi)", "sip:" .. from .. "@" .. KAM_DOMAIN)
KSR.pv.sets("$uac_req(turi)", "sip:" .. to .. "@" .. KAM_DOMAIN)
KSR.pv.seti("$uac_req(evroute)", 1)
KSR.pv.sets("$uac_req(body)", content)
local ouri = (row.received ~= "" and row.received) or row.contact
KSR.pv.sets("$uac_req(ouri)", ouri)
local callid = rows[i].clientid .. "`" .. rows[i].username .. "`" .. os.time()
KSR.pv.sets("$uac_req(callid)", callid)
KSR.uac.uac_req_send()
Hello,
Im gathering ideas about routing based on caller number to multiple peers and -lets say- subscribers.
As far as i know we can route the calls with LCR based on prefix or the whole number to the LCR gateways which are specified in the LCR module gateway table.
This is working very well with public IP based "peers". We can route calls to these gateways.
But what can we do if we have to route to a "peer" which is behind NAT. Basically they have to REGISTER as a subscriber, but we cannot add a subscriber to the LCR gateway table, beacuse LCR module needs a directly reachable IP address with a fixed port.
Does anyone have any ideas on how to handle these mixed type peers?
Or maybe we have to add the fixed IP peers which are not REGISTERing to the usrloc database somehow and then we can do a lookup location based on $rU.
To make myself clear, it would be nice if we can handle those 2 types of our peers unifromly in terms of SIP routing, thats why im looking for a "unified" solution.
Thanks for your suggestions.
With kind regards,
Zoltan
Hi all
Is there a way to skip a branch in branch route?
Situation: Two registrar server with DMQ synced location database.
CPE register via TCP or TLS. To properly work, message have to be sent
over the existing TCP connection.
Multiple CPE register to one AOR.
CPE1 and CPE2 register to Registrar 1
CPE3 registers to Registrar 2
On Registrar 1 there is an established TCP connection to CPE1 and CPE2
but not to CPE3.
Within the Branch Route to the CPE I can check if there is a TCP
as the Branch Route is executed for every contact in that AOR:
branch_route[BR_TO_CPE]
{
[...]
$var(reg_contact_addr) = $(ulc(aor=>addr)[$T_branch_idx]{uri.host});
$var(socket) = $(ulc(aor=>socket)[$T_branch_idx]);
if ($var(socket) == 0) {
xlog("L_ERROR", "$cfg(route): No Socket for: $var(reg_contact_addr)");
}
[...]
}
This log an error if the socket is not present on the local registrar.
But is there a way to tell kamailio to skip/discard that contact?
My intention is to parallel branch from the core to both registrars,
that way all contacts would still get the call but via established
TCP socket (and in case of UDP and NAT via correct know ip for ALG port-forwarding).
--
Mit freundlichen Grüssen
-Benoît Panizzon- @ HomeOffice und normal erreichbar
--
I m p r o W a r e A G - Leiter Commerce Kunden
______________________________________________________
Zurlindenstrasse 29 Tel +41 61 826 93 00
CH-4133 Pratteln Fax +41 61 826 93 01
Schweiz Web http://www.imp.ch
______________________________________________________
Hello everyone!
I'm running Kamailio 5.6.2 and having a potential problem on one of the
systems. The Slow timer process slowly consumes more and more of its PKG
memory. I did not allow it to use all memory by restartink Kamailio during
afterhours so I'm not sure what the consequences might be.
I'm suspecting that this could be caused by my configuration but not sure
how exactly. Can anyone please tell me how the Slow timer process can be
debugged? Is it possible to see what it is storing in the memory and what
data is piling up?
Thanks a lot!
Regarts, Volodymyr Ivanets.
Hello all,
I'm currently working on a proxy where I need to change To and From headers
in order to normalize the numbers to +E164.
I would like to be able to restore using and $avp() or $dlg_var() and
without writing parameters on the Record-Route headers.
I've tried to use restore_mode in auto mode and restore_dlg parameter with
value 1 but still got the parameters on the inserted Record-Route.
I've tried manual mode and using the configured $avp() to restore, but the
parameters still got written on the Request-URI.
I thought of using restore_mode with value "none" saving original values in
an $avvp() and doing the replace, however, uac_replace() on Request Route
or branch routes. That way i can't replace the values of To and From in the
replies.
That being said, my questions are :
- Is there a way to use manual or auto mode without writing info on the
Record-Route and only using $avp() ?
- Is there a way to make changes on the To and From header on replies?
Thanks in advance,
Best Regards,
Duarte Rocha
Hello!
Are there any technical difficulties in adding tlsa module with the
statically linked OpenSSL v1.1.1 to the package builder (deb)?
--
BR,
Denys Pozniak
**Issue Description**
I'm encountering an issue with my Kamailio configuration related to the inclusion of the "Accounting-Record-Type" (480) and "Accounting-Record-Number" (485) AVPs in Credit-Control Request (CCR) messages sent from the S-CSCF to the OCS.
**Issue Details**
- **Problem**: The "Accounting-Record-Type" and "Accounting-Record-Number" AVPs are being added to CCR messages generated by my Kamailio instance.
- **Expected Behavior**: According to modern Diameter and 3GPP standards (e.g., RFC 4006 and TS 32.299), these AVPs should not be included in CCR messages.
**Configuration Details**
- **Kamailio Version**: 5.3.0
- **SigScale OCS Version**: 3.2.9
Note that I have redacted some specific information for confidentiality reasons. The actual values are placed in my Kamailio main configuration file (`kamailio.cfg`) and Diameter-specific configuration files (where applicable).
Kamailio.cfg:
modparam("ims_charging", "db_url", DB_URL)
modparam("ims_charging", "db_mode", 1)
modparam("ims_charging", "origin_host", HOSTNAME);
modparam("ims_charging", "origin_realm", NETWORKNAME);
modparam("ims_charging", "destination_host", DESTINATION_HOST);
modparam("ims_charging", "destination_realm", DESTINATION_REALM);
modparam("ims_charging","service_context_id_root", RO_ROOT);
modparam("ims_charging","service_context_id_ext", RO_EXT);
modparam("ims_charging","service_context_id_mnc", MNC);
modparam("ims_charging","service_context_id_mcc", MCC);
modparam("ims_charging","interim_update_credits",30);
modparam("ims_charging","timer_buffer",5);
SCSCF.xml:
<?xml version="1.0" encoding="UTF-8"?>
<DiameterPeer
FQDN="scscf.mncXXX.mccXXX.3gppnetwork.org"
Realm="ims.mncXXX.mccXXX.3gppnetwork.org"
Vendor_Id="10415"
Product_Name="CDiameterPeer"
AcceptUnknownPeers="1"
DropUnknownOnDisconnect="1"
Tc="30"
Workers="16"
QueueLength="32"
TransactionTimeout="5"
SessionsHashSize="128"
DefaultAuthSessionTimeout="3600"
MaxAuthSessionTimeout="3600"
>
<Peer FQDN="diameter" Realm="ims.mncXXX.mccXXX.3gppnetwork.org" port="3868"/>
<Peer FQDN="192.168.2.31" Realm="ocs.ims.mncXXX.mccXXX.3gppnetwork.org" port="3868"/>
<Acceptor port="3868" bind="eth0"/>
<Auth id="16777216" vendor="10415"/><!-- 3GPP Cx -->
<Auth id="16777216" vendor="4491"/><!-- CableLabs Cx -->
<Auth id="16777216" vendor="13019"/><!-- ETSI/TISPAN Cx -->
<Auth id="16777216" vendor="0"/><!-- ETSI/TISPAN Cx -->
<Auth id="4" vendor="10415"/> <!--3GPP Ro -->
<Acct id="4" vendor="10415" />
<!--
Supported Vendor IDs - list of values which will be sent in the CER/CEA in the
Supported-Vendor-ID AVPs
-->
<SupportedVendor vendor="10415" />
<Realm name="ocs.ims.mncXXX.mccXXX.3gppnetwork.org">
<Route FQDN="192.168.2.31" metric="10"/>
</Realm>
<DefaultRoute FQDN="diameter" metric="10"/>
</DiameterPeer>
I am using SigScale OCS as my Online Charging System. Here is the error log I received from SigScale OCS:
ERROR REPORT==== 5-Sep-2023::07:27:01.393554 ===
"DIAMETER AVP unsupported"
service_name: {ocs_diameter_acct_service,{0,0,0,0},3868}
capabilities: {diameter_caps,
{<<"host1">>, <<"scscf-1.ims.mncXXX.mccXXX.3gppnetwork.org">>},
{<<"COMPANYNAME.local">>, <<"ims.mncXXX.mccXXX.3gppnetwork.org">>},
{[{0,0,0,0}],[{172,18,0,7}]},
{50386,10415},
{<<"SigScale OCS">>,<<"CDiameterPeer">>},
{[],[]},
{[10415],[10415]},
{[4,16777238],[16777216]},
{[],[]},
{[],[]},
{[{'diameter_base_Vendor-Specific-Application-Id',10415,[16777238],[]}],
[{'diameter_base_Vendor-Specific-Application-Id',10415,[16777216],[]},
{'diameter_base_Vendor-Specific-Application-Id',4491,[16777216],[]},
{'diameter_base_Vendor-Specific-Application-Id',13019,[16777216],[]},
{'diameter_base_Vendor-Specific-Application-Id',10415,[4],[]},
{'diameter_base_Vendor-Specific-Application-Id',10415,[],[4]}]},
{[329],[]},
{[],[]}}
errors: [{5001,
{diameter_avp,480,undefined,true,false,
<<0,0,0,2>>,
'Accounting-Record-Type',2,'Enumerated',5}},
{5001,
{diameter_avp,485,undefined,true,false,
<<0,0,0,0>>,
'Accounting-Record-Number',0,'Unsigned32',6}},
{5001,
{diameter_avp,260,undefined,true,false,
<<0,0,1,10,64,0,0,12,0,0,40,175,0,0,1,2,64,0,0,12,0,0,0,4>>,
'Vendor-Specific-Application-Id',
{'3gpp_ro_Vendor-Specific-Application-Id',10415,[4],[]},
'Grouped',10}}]
I would greatly appreciate it if someone from the community could provide insights into the following:
1. Possible Configurations: Are there specific configurations or modules in Kamailio that might cause the inclusion of non-standard AVPs in CCR messages?
2. IMS Ro Interface Behavior: Does anyone have experience with IMS Ro interface behavior using Kamailio that could shed light on this?
If you have any guidance, suggestions, or solutions to help me troubleshoot and resolve this problem, please share them. Thank you for your assistance.
Hello,
Running ”kamcmd permissions.trustedReload” it instantly returns “Reload OK” but I cannot repeat the reload for about 8 seconds. This is the same for dialplan.reload and dispatcher.reload.
root@superman.local:/# kamcmd permissions.trustedReload
Reload OK
root@superman.local:/# kamcmd permissions.trustedReload
error: 500 - ongoing reload
root@superman.local:/# kamcmd permissions.trustedReload
error: 500 - ongoing reload
There are scenarios where I might need to reload the permission table multiple times within this 8 second window. Is this some kind of intended block or is something at fault?
modparam("db_mysql", "ping_interval", 60)
modparam("db_mysql", "timeout_interval", 4)
modparam("db_mysql", "auto_reconnect", 1)
modparam("db_mysql", "opt_ssl_mode", 0)
modparam("permissions", "db_url", "mysql://kamailio:xxxxx@aws-rds-database /kamailio")
version: kamailio 5.7.1 (x86_64/linux)
flags: USE_TCP, USE_TLS, USE_SCTP, TLS_HOOKS, USE_RAW_SOCKS, DISABLE_NAGLE, USE_MCAST, DNS_IP_HACK, SHM_MMAP, PKG_MALLOC, MEM_JOIN_FREE, Q_MALLOC, F_MALLOC, TLSF_MALLOC, DBG_SR_MEMORY, USE_FUTEX, FAST_LOCK-ADAPTIVE_WAIT, USE_DNS_CACHE, USE_DNS_FAILOVER, USE_NAPTR, USE_DST_BLOCKLIST, HAVE_RESOLV_RES, TLS_PTHREAD_MUTEX_SHARED
ADAPTIVE_WAIT_LOOPS 1024, MAX_RECV_BUFFER_SIZE 262144, MAX_URI_SIZE 1024, BUF_SIZE 65535, DEFAULT PKG_SIZE 8MB
poll method support: poll, epoll_lt, epoll_et, sigio_rt, select.
id: unknown
compiled with gcc 10.2.1
/M
Is there any specific reason why shared memory can be configured via the
config files ("shm_mem_size") AND CLI flags ("-m") but package memory can
only be set via CLI flags ("-M")?
Did no one ever came across the need to configure the package memory limit
so far, or is there another way to achieve it without using the CLI flag?
--
Ivan Ribakov
Software Engineer
www.zaleos.net
Bastian,
According to mine stats all seems ok...
# kamctl stats shmem
{
"jsonrpc": "2.0",
"result": [
"shmem:fragments = 330",
"shmem:free_size = 1889418024",
"shmem:max_used_size = 258962624",
"shmem:real_used_size = 258065624",
"shmem:total_size = 2147483648",
"shmem:used_size = 248809096"
],
"id": 212042
}
pkg.stats also not showing any signs of exhausting.
For me what is working is server can send packets, but not receive em
back even. And it's happening only on 1 interface.
Le 30/08/2023 à 21:44, Bastian Triller a écrit :
> I'm asking, because we kind of observed similar behaviour after
> overload. We've did some load testing and at some point SHM was
> exhausted and that didn't recover itself. One process was using nearly
> 100% CPU. And I guess that at least sl replies still works at that point.
>
> On Wed, Aug 30, 2023 at 9:28 PM Ihor Olkhovskyi
> <igorolhovskiy(a)gmail.com> wrote:
>
> Bastian,
>
> I'm fine with retransmissions and so, but for me it's really
> interesting, that server is not restoring it's state after a while
> and only restart helps. And this is happening only with UDP on one
> interface, others are working fine over UDP
>
> Le 30/08/2023 à 17:19, Bastian Triller a écrit :
>> Maybe it's not beneficial to have a receive buffer that high. If
>> your presence server is stateful, it will send retransmissions if
>> packets get dropped. But it will also send retransmissions if
>> your proxy does not reply fast enough. So your proxy may be
>> damped by retransmissions. Did you check SHM/active transactions
>> on your proxy?
>>
>> Regards,
>> Bastian
>>
>> On Wed, Aug 30, 2023 at 3:56 PM Ihor Olkhovskyi
>> <igorolhovskiy(a)gmail.com> wrote:
>>
>> They are increasing, actually
>>
>> # ss -l -u -m src X.X.X.X/Y
>> State Recv-Q Send-Q Local
>> Address:Port Peer Address:Port
>> UNCONN 25167616 0 X.X.X.X:sip *:*
>> skmem:(r25167616,rb25165824,t0,tb65536,f2304,w0,o0,bl0,d514894)
>>
>> Le mer. 30 août 2023 à 15:04, Bastian Triller
>> <bastian.triller(a)gmail.com> a écrit :
>>
>> Are drops increasing on that socket while it is happening?
>> ss -l src <local_interface> -u sport 5060 -m
>>
>> On Tue, Aug 29, 2023 at 3:26 PM Ihor Olkhovskyi
>> <igorolhovskiy(a)gmail.com> wrote:
>>
>> Just to add some info
>>
>> netstat -nlp
>> Active Internet connections (only servers)
>> Proto Recv-Q Send-Q Local Address Foreign Address
>> State PID/Program name
>> ...
>> udp 25167616 0 <local_interface>:5060
>> 0.0.0.0:* 211759/kamailio
>> ...
>>
>> So I see a huge Receive Queue on UDP for Kamailio
>> which is not clearing.
>>
>> Le mar. 29 août 2023 à 14:29, Ihor Olkhovskyi
>> <igorolhovskiy(a)gmail.com> a écrit :
>>
>> Hello,
>>
>> I've faced a bit strange issue, but a bit of
>> preface. I have Kamailio as a proxy (TLS/WS <->
>> UDP) and second Kamailio as a presence server. At
>> some point presence server accepts around 5K
>> PUBLISH within 1 minute and sending around the
>> same amount of NOTIFY to proxy Kamailio.
>>
>> Proxy is "transforming" protocol to TLS, but at
>> sime point I'm starting to get these type of errors
>>
>> tm [../../core/forward.h:292]: msg_send_buffer():
>> tcp_send failed
>> tm [t_fwd.c:1588]: t_send_branch(): sending
>> request on branch 0 failed
>> <script>: [RELAY] Relay to
>> <sip:X.X.X.X:51571;transport=tls> failed!
>> tm [../../core/forward.h:292]: msg_send_buffer():
>> tcp_send failed
>> tm [t_fwd.c:1588]: t_send_branch(): sending
>> request on branch 0 failed
>>
>> Some of those messages are 100% valid as client
>> can go away or so. Some are not, cause I'm sure
>> client is alive and connected.
>>
>> But the problem comes later. At some moment proxy
>> Kamailio just stops accept UDP traffic on this
>> interface (where it also accepts all NOTIFY's),
>> at the start of the "stopping accepting" Kamailio
>> sends OPTIONS via DISPATCHER but not able to
>> receive 200 OK.
>>
>> Over TLS on the same interface all is ok. On
>> other (loopback) interface UDP is being processed
>> fine, so I don't suspert some limit on open files
>> here.
>>
>> Only restart of Kamailio proxy process helps in
>> this case.
>>
>> I've tuned net.core.rmem_max and
>> net.core.rmem_default to 25 Mb, so in theory
>> buffer should not be the case.
>>
>> Is there some internal "interface buffer" in
>> Kamailio that is not freed upon failure send or
>> maybe I've missed somethig?
>>
>> Kamailio 5.6.4
>>
>> fork=yes
>> children=12
>> tcp_children=12
>>
>> enable_tls=yes
>>
>> tcp_accept_no_cl=yes
>> tcp_max_connections=63536
>> tls_max_connections=63536
>> tcp_accept_aliases=no
>> tcp_async=yes
>> tcp_connect_timeout=10
>> tcp_conn_wq_max=63536
>> tcp_crlf_ping=yes
>> tcp_delayed_ack=yes
>> tcp_fd_cache=yes
>> tcp_keepalive=yes
>> tcp_keepcnt=3
>> tcp_keepidle=30
>> tcp_keepintvl=10
>> tcp_linger2=30
>> tcp_rd_buf_size=80000
>> tcp_send_timeout=10
>> tcp_wq_blk_size=2100
>> tcp_wq_max=10485760
>> open_files_limit=63536
>>
>> Sysctl
>>
>> # To increase the amount of memory available for
>> socket input/output queues
>> net.ipv4.tcp_rmem = 4096 25165824 25165824
>> net.core.rmem_max = 25165824
>> net.core.rmem_default = 25165824
>> net.ipv4.tcp_wmem = 4096 65536 25165824
>> net.core.wmem_max = 25165824
>> net.core.wmem_default = 65536
>> net.core.optmem_max = 25165824
>>
>> # To limit the maximum number of requests queued
>> to a listen socket
>> net.core.somaxconn = 128
>>
>> # Tells TCP to instead make decisions that would
>> prefer lower latency.
>> net.ipv4.tcp_low_latency=1
>>
>> # Optional (it will increase performance)
>> net.core.netdev_max_backlog = 1000
>> net.ipv4.tcp_max_syn_backlog = 128
>>
>> # Flush the routing table to make changes happen
>> instantly.
>> net.ipv4.route.flush=1
>> --
>> Best regards,
>> Ihor (Igor)
>>
>>
>>
>> --
>> Best regards,
>> Ihor (Igor)
>> __________________________________________________________
>> Kamailio - Users Mailing List - Non Commercial
>> Discussions
>> To unsubscribe send an email to
>> sr-users-leave(a)lists.kamailio.org
>> Important: keep the mailing list in the recipients,
>> do not reply only to the sender!
>> Edit mailing list options or unsubscribe:
>>
>> __________________________________________________________
>> Kamailio - Users Mailing List - Non Commercial Discussions
>> To unsubscribe send an email to
>> sr-users-leave(a)lists.kamailio.org
>> Important: keep the mailing list in the recipients, do
>> not reply only to the sender!
>> Edit mailing list options or unsubscribe:
>>
>>
>>
>> --
>> Best regards,
>> Ihor (Igor)
>> __________________________________________________________
>> Kamailio - Users Mailing List - Non Commercial Discussions
>> To unsubscribe send an email to sr-users-leave(a)lists.kamailio.org
>> Important: keep the mailing list in the recipients, do not
>> reply only to the sender!
>> Edit mailing list options or unsubscribe:
>>
>>
>> __________________________________________________________
>> Kamailio - Users Mailing List - Non Commercial Discussions
>> To unsubscribe send an email tosr-users-leave(a)lists.kamailio.org
>> Important: keep the mailing list in the recipients, do not reply only to the sender!
>> Edit mailing list options or unsubscribe:
>
Hi people,
I installed Kamailio 5.3 on Ubuntu Server 22 LTS, but I am not able to resolve several PHP errors that occur when I try to open the website http://localhost/siremis/.
Which Linux distro and version is best suited for installation?
Is Kamailio version 5.3 operational or is it better to use version 4.4?
Att.,
Daniel Hilário
INFRACOM/UFRGS
51 3308 4801
Hello,
I've faced a bit strange issue, but a bit of preface. I have Kamailio as a
proxy (TLS/WS <-> UDP) and second Kamailio as a presence server. At some
point presence server accepts around 5K PUBLISH within 1 minute and sending
around the same amount of NOTIFY to proxy Kamailio.
Proxy is "transforming" protocol to TLS, but at sime point I'm starting to
get these type of errors
tm [../../core/forward.h:292]: msg_send_buffer(): tcp_send failed
tm [t_fwd.c:1588]: t_send_branch(): sending request on branch 0 failed
<script>: [RELAY] Relay to <sip:X.X.X.X:51571;transport=tls> failed!
tm [../../core/forward.h:292]: msg_send_buffer(): tcp_send failed
tm [t_fwd.c:1588]: t_send_branch(): sending request on branch 0 failed
Some of those messages are 100% valid as client can go away or so. Some are
not, cause I'm sure client is alive and connected.
But the problem comes later. At some moment proxy Kamailio just stops
accept UDP traffic on this interface (where it also accepts all NOTIFY's),
at the start of the "stopping accepting" Kamailio sends OPTIONS via
DISPATCHER but not able to receive 200 OK.
Over TLS on the same interface all is ok. On other (loopback) interface UDP
is being processed fine, so I don't suspert some limit on open files here.
Only restart of Kamailio proxy process helps in this case.
I've tuned net.core.rmem_max and net.core.rmem_default to 25 Mb, so in
theory buffer should not be the case.
Is there some internal "interface buffer" in Kamailio that is not freed
upon failure send or maybe I've missed somethig?
Kamailio 5.6.4
fork=yes
children=12
tcp_children=12
enable_tls=yes
tcp_accept_no_cl=yes
tcp_max_connections=63536
tls_max_connections=63536
tcp_accept_aliases=no
tcp_async=yes
tcp_connect_timeout=10
tcp_conn_wq_max=63536
tcp_crlf_ping=yes
tcp_delayed_ack=yes
tcp_fd_cache=yes
tcp_keepalive=yes
tcp_keepcnt=3
tcp_keepidle=30
tcp_keepintvl=10
tcp_linger2=30
tcp_rd_buf_size=80000
tcp_send_timeout=10
tcp_wq_blk_size=2100
tcp_wq_max=10485760
open_files_limit=63536
Sysctl
# To increase the amount of memory available for socket input/output queues
net.ipv4.tcp_rmem = 4096 25165824 25165824
net.core.rmem_max = 25165824
net.core.rmem_default = 25165824
net.ipv4.tcp_wmem = 4096 65536 25165824
net.core.wmem_max = 25165824
net.core.wmem_default = 65536
net.core.optmem_max = 25165824
# To limit the maximum number of requests queued to a listen socket
net.core.somaxconn = 128
# Tells TCP to instead make decisions that would prefer lower latency.
net.ipv4.tcp_low_latency=1
# Optional (it will increase performance)
net.core.netdev_max_backlog = 1000
net.ipv4.tcp_max_syn_backlog = 128
# Flush the routing table to make changes happen instantly.
net.ipv4.route.flush=1
--
Best regards,
Ihor (Igor)
Hello,
I have a Kamailio SBC connected to another foreign SBC and to a media server.
In case of non response, Kamailio SBC receives a 480 Temporarily not available from the foreign SBC and I need to forward this 480 to my media server but I don't see how to do that.
The 480 arrives in the onreply_route. If I use then a failure_route, it resends the initial INVITE and not the 480.
Is there a way to do that?
Thanks for your help.
Anthony Blandin
I think is better sip over tls to extra protection xD
Sent from Android device
El 26 ago 2023 12:59, Julien Chavanton <jchavanton(a)gmail.com> escribió:
Are you trying to connect them over SIP ?
On Sat, Aug 26, 2023, 6:06 AM <feigelwang(a)uusextoy.com <mailto:feigelwang@uusextoy.com> > wrote:
So, when you still are alone, buying a huge dildo is worth it. Enjoy sex with the huge realistic dildo anytime and anywhere. Not only that, the big dildo brings completely different sexual stimulation. Maybe you want to enjoy full sex, should try some other sex toys.
https://www.hugedildo.com/
__________________________________________________________
Kamailio - Users Mailing List - Non Commercial Discussions
To unsubscribe send an email to sr-users-leave(a)lists.kamailio.org <mailto:sr-users-leave@lists.kamailio.org>
Important: keep the mailing list in the recipients, do not reply only to the sender!
Edit mailing list options or unsubscribe:
So, when you still are alone, buying a huge dildo is worth it. Enjoy sex with the huge realistic dildo anytime and anywhere. Not only that, the big dildo brings completely different sexual stimulation. Maybe you want to enjoy full sex, should try some other sex toys.
https://www.hugedildo.com/
Or, if you are good at Google search, I believe you can definitely find more ways to play the big dildo. All in all, huge dildos are the best sex toy for singles. For single women, it’s vaginal masturbation. For single men, it’s anal sex.
https://www.hugedildo.com/
Or, if you are good at Google search, I believe you can definitely find more ways to play the big dildo. All in all, huge dildos are the best sex toy for singles. For single women, it’s vaginal masturbation. For single men, it’s anal sex.https://www.hugedildo.com/
So, when you still are alone, buying a huge dildo is worth it. Enjoy sex with the huge realistic dildo anytime and anywhere. Not only that, the big dildo brings completely different sexual stimulation. Maybe you want to enjoy full sex, should try some other sex toys.https://www.hugedildo.com/
hi,
i have open around ~8000 rtp ports for around ~200calls (in peak)
with this statistic (current data, not from peak)
rtpengine_closed_sessions_total{reason="rejected"} 0
rtpengine_closed_sessions_total{reason="timeout"} 237405
rtpengine_closed_sessions_total{reason="silent_timeout"} 103
rtpengine_closed_sessions_total{reason="final_timeout"} 0
rtpengine_closed_sessions_total{reason="offer_timeout"} 0
rtpengine_closed_sessions_total{reason="terminated"} 0
rtpengine_request_seconds_total{proxy="127.0.0.1",request="offer"}
539.270967
rtpengine_request_seconds_total{proxy="127.0.0.1",request="answer"}
367.237641
rtpengine_request_seconds_total{proxy="127.0.0.1",request="delete"} 0.000000
is it normal? (large number of timeouts, "zero" terminated)
or i have missing rtpengine_manage (rtpengine_delete) somewhere?
(os rocky 9.2, kamailio 5.6.4, rtpengine 11.3.1)
thanks
Marek
Hi,
I would like to force the transport protocol between the I-CSCF and S-CSCF to be TCP only. How would I do that exactly?
I'm using an older Kamailio release 5.0.8.
Regards,
Hello,
We want to check if the number in a REFER's Refer-To header begins with
011, and if so reject the request as not allowed. What would be the most
effective way to do that?
Thanks in advance,
--
David Cunningham, Voisonics Limited
http://voisonics.com/
USA: +1 213 221 1092
New Zealand: +64 (0)28 2558 3782
I am trying to set a value to an avp on the request route, but when I
try to read the avp on the reply route I always get nil.
On the route I have this:
KSR.xlog.xinfo("invite_request: ********** Setting avp test\n")
KSR.pv.seti("$avp(test)", 1)
KSR.xlog.xinfo("invite_request: **** " ..
tostring(KSR.pv.get("$avp(test)")).."\n")
On the reply route I have this:
KSR.xlog.xinfo("response_invite: **** " ..
tostring(KSR.pv.get("$avp(test)")).."\n")
In the logs I see on the INVITE:
Aug 8 13:49:15 test /usr/sbin/kamailio[1927947]: INFO:
[a0748d39-3f17-4080-b5ed-0a6b7019cb95 INVITE 1]invite_request:
********** Setting avp test
Aug 8 13:49:15 test /usr/sbin/kamailio[1927947]: INFO:
[a0748d39-3f17-4080-b5ed-0a6b7019cb95 INVITE 1]invite_request: **** 1
...
...
Aug 8 13:49:15 test /usr/sbin/kamailio[1927968]: INFO:
[a0748d39-3f17-4080-b5ed-0a6b7019cb95 INVITE 2]response_invite: ****
nil
Do avp not cover the transaction?