Hello,
please keep the list in CC.
Not sure what you mean by multi-process safe. The functions are safe to use in a kamailio multi-process context, relevant sections should be protected by internal locks etc..
Regarding query location manually by SQL client, its better to use the provided functions from the usrloc/registrar module instead.
Cheers,
Henning
--
Henning Westerholt – https://skalatan.de/blog/
Kamailio services – https://gilawa.com<https://gilawa.com/>
From: riffs(a)sina.cn <riffs(a)sina.cn>
Sent: Thursday, December 1, 2022 10:47 AM
To: Henning Westerholt <hw(a)gilawa.com>
Subject: Re: Re: [SR-Users] uac_req_send() multi-process synchronization problem
To confirm that. Are reg_fetch_contacts and unregister_ruid multi-process safe?
________________________________
riffs(a)sina.cn<mailto:riffs@sina.cn>
From: riffs(a)sina.cn<mailto:riffs@sina.cn>
Date: 2022-12-01 16:35
To: Henning Westerholt<mailto:hw@gilawa.com>
Subject: Re: RE: [SR-Users] uac_req_send() multi-process synchronization problem
Hello
Thank you for your reply very much. My LOCATION is stored in the MYSQL database, and I also set the event_callback parameter of TCPOPS.
modparam("tcpops", "event_callback", "ksr_tcpops_event")
At the same time.I also deleted the contact inside the function
function ksr_tcpops_event(evname)
local tcpconnid = KSR.pv.get("$conid") or "0"
if (evname == "tcp:reset" or evname == "tcp:closed") and (tonumber(tcpconnid) ~= 0) then
local sql = string.format("select * from location where tcpconnid=%s", tcpconnid)
local count, rows = execute_select(sql)
if count > 0 then
KSR.registrar.unregister_ruid("location", rows[1].contact, rows[1].ruid)
end
end
return 1
end
When I use use_req_send(), I use the following sql statement to query location
string.format("select * from location where username='%s'", reciever)
I think because the query sql is executed before the execution of unregister_ruid completes, the location of user A can still be queried.
If unregister_ruid and reg_fetch_contacts are multi-process safe. I use reg_fetch_contacts query location to avoid this problem. Is that so?
thanks very much
________________________________
riffs(a)sina.cn<mailto:riffs@sina.cn>
From: Henning Westerholt<mailto:hw@gilawa.com>
Date: 2022-11-30 18:18
To: Kamailio (SER) - Users Mailing List<mailto:sr-users@lists.kamailio.org>
CC: 刘建峰<mailto:riffs@sina.cn>
Subject: RE: [SR-Users] uac_req_send() multi-process synchronization problem
Hello,
not sure if I fully understand the problem. But regarding another user is registered with the same IP address as a previous user, there are several mitigations.
To give two options: you could choose a really short re-registration time, you could use TCP and when you lose the connection you delete the contact.
Cheers,
Henning
--
Henning Westerholt – https://skalatan.de/blog/
Kamailio services – https://gilawa.com<https://gilawa.com/>
From: sr-users <sr-users-bounces(a)lists.kamailio.org<mailto:sr-users-bounces@lists.kamailio.org>> On Behalf Of ???
Sent: Wednesday, November 30, 2022 2:57 AM
To: sr-users(a)lists.kamailio.org<mailto:sr-users@lists.kamailio.org>
Subject: [SR-Users] uac_req_send() multi-process synchronization problem
When I use uac_req_send() to send a MESSAGE to the client. Will the following occur? The result of the message sent to user A is that B has received it. From the logs, the address of user A in the location table is the same as the IP address and port of user B, and the information of user A in the location table is not deleted in time. I took the address of user A directly from the location table without using KSR.registrar.reg_fetch_contacts(). If I use KSR.registrar.reg_fetch_contacts() can this be avoided. This is a multi-process synchronization problem, after user A registers, the IP port information in the address is 172.16.22.222:12345, and then user A disconnects the link because of some abnormal conditions, but it is not normal to cancel the registration, the socket link has failed, but it has not had time to delete the location, at this time user B registers, whether will it get the same IP port information as user A 172.16.22.222 : 12345, if possible? User A's location still exists, Using KSR.registrar.reg_fetch_contacts() TO query user A's location, and then using uac_req_send() to send a message to user A, User B will receive the MESSAGE. Whether this problem occurs?
从 Windows 版邮件<https://go.microsoft.com/fwlink/?LinkId=550986>发送
Hello!
Is it possible to find out the name of the onreply_route that was set
before?
Something like this:
t_on_reply("MANAGE_REPLY");
...
if ( t_is_set("onreply_route") ) {
get_onreply_route_name();
...
}
--
BR,
Denys Pozniak
Hello,
should anyone be interested to present or just go to FOSDEM 2023, note
that it is going to take place in Brussels during February 4-5, 2023.
With a increasing demand on topics to be covered, many more devrooms
were accepted and Real Time Communication devroom has half a day
available on the afternoon of February 5, 2023. The RTC Devroom call for
presentations is open, more details at;
- https://lists.fosdem.org/pipermail/fosdem/2022q4/003479.html
Check also the other accepted devrooms, maybe one suits better for your
work with open source nowadays and you can submit proposals to them:
- https://fosdem.org/2023/news/2022-11-07-accepted-developer-rooms/
Cheers,
Daniel
--
Daniel-Constantin Mierla -- www.asipto.comwww.twitter.com/miconda -- www.linkedin.com/in/miconda
Greetings!
I have a CentOS setup in AWS where all my calls are dropped after about a
minute or so. I realize this typically is a NAT problem, but I can't see
where my error is.
Sound is fine both ways.
Kamailio is set with WITH_NAT and I use rtpproxy like this:
OPTIONS="-l 10.1.2.10 -s udp:127.0.0.1:7722 -d INFO:LOG_LOCAL5 -m 35010 -M
35110 -A 54.171.168.48"
(10.1.2.10 is the local IP for CentOS)
Tested with MicroSIP and Linphone and tried numerous configurations. It
seems the receiving client is not able to verify the call has been set up,
and disconnects. MicroSIP has the status "Connecting..." until it
disconnects.
All tips appreciated. Will post configuration and logs if needed.
Kamailio version 5.6.2 from rpm and rtpproxy 2.1.0 compiled from source.
--
Regards
Christian B. Wiik
Hello All,
I have a setup where the DNS server is configured with only A record. When
the Kamailio receives the request it performs a DNS SRV query for which it
receives a response with "no such name". But later a DNS A query is sent
which gets resolved and the request is forwarded.
I would like to know that is there any configuration that can be done in
Kamailio so that it will perform only DNS A query directly instead of SRV
query? If so could you please help me know how to do it
Thanks and Regards
Arun
Dear List
In the last week I try to figure out how I can put in place a
configuration that use an edge proxy and a register by using kamailio
5.6, but i am facing some issues.
Scenario:
We are using on ubuntu 20.04, HAproxy and Kamailio 5.6.
We have configured a Kamailio register that, in the following case,
perfectly works.
______ __ __________
TLS | | TLS
| |
Client ------------------ > | NAT |-----------> | Kamalio |
in |_HAProxy | out in | Register |
|_________| | |
|________ _|
Now we want to put a kamailio edge proxy before the kamailio Register,
please take a look to the below picture
______
______ __ _________
___________
TLS | | TLS |
| TCP | |
Client ------------------ > | NAT |-----------> | Kamalio |
-------------> | Kamailio |
in |_HAProxy | out in | Edge | out
in | Register |
|_________| | Proxy
| | |
|_________| |___________|
HAproxy -> sip-test.example.com
Kamailio edge proxy -> 192.168.58.1
Kamailio Register -> 192.168.58.15
The kamailio Edge has been configured as indicated in the outbound
module example.
When a transaction such as REGISTER or SUBSCRIBE reach the "Kamailio
Register" the Record-Route and Via headers are correct and it works.
When the transaction such as MESSAGE or INVITE reach the "Kamailio
Register" it does not work and below you can see the message and the error.
Note that the Record-Route and Via headers are the same as the previous
message REGISTER and SUBSCRIBE.
Dec 6 11:57:09 qcast-webserver-dev /usr/sbin/kamailio[15340]: INFO: {1
40742 MESSAGE YsfZ7Rq-WGw33NUn9AFMWEuurzryvzET} <script>:
SIPMessage-in-request =
192.168.58.1:53606-sip:s-user.02@sip-dev.example.com-MESSAGE
sip:s-user.02@sip-dev.example.com SIP/2.0
Record-Route: <sip:192.168.58.1:15006;transport=tcp;r2=on;lr>
Record-Route: <sip:sip-test.example.com:16005;transport=tls;r2=on;lr>
Via: SIP/2.0/TCP
192.168.58.1:15006;branch=z9hG4bKa257.add27f134dd83c78aef13ca7798f87ca.0;i=6
Via: SIP/2.0/TLS
192.168.58.1:39592;received=192.168.58.1;rport=39592;branch=z9hG4bKPjajkY.0NlW2AFuz3.BRaKH4EdvdmQTs9L;alias
Max-Forwards: 69
From:
<sip:s-user.03@sip-dev.example.com>;tag=VnOekkKsq4tLhFAywXzbxLXxIesWscn3
To: <sip:s-user.02@sip-dev.example.com>
Call-ID: YsfZ7Rq-WGw33NUn9AFMWEuurzryvzET
CSeq: 40742 MESSAGE
Accept: text/plain, application/im-iscomposing+xml
Content-Type: text/plain
Content-Length: 59
################## MESSAGE ###################
Dec 6 11:57:09 qcast-webserver-dev /usr/sbin/kamailio[15340]: INFO: {1
40743 MESSAGE YsfZ7Rq-WGw33NUn9AFMWEuurzryvzET} <script>:
SIPMessage-in-request =
192.168.58.1:53606-sip:s-user.02@sip-dev.example.com-MESSAGE
sip:s-user.02@sip-dev.example.com SIP/2.0
Record-Route: <sip:192.168.58.1:15006;transport=tcp;r2=on;lr>
Record-Route: <sip:sip-test.example.com:16005;transport=tls;r2=on;lr>
Via: SIP/2.0/TCP
192.168.58.1:15006;branch=z9hG4bKb257.83b972054df1675806975159ae1f1e43.0;i=6
Via: SIP/2.0/TLS
192.168.58.1:39592;received=192.168.58.1;rport=39592;branch=z9hG4bKPjfan-Tte.vtL8brkWb20wm.5b8iuVEtQV;alias
Max-Forwards: 69
From:
<sip:s-user.03@sip-dev.example.com>;tag=VnOekkKsq4tLhFAywXzbxLXxIesWscn3
To: <sip:s-user.02@sip-dev.example.com>
Call-ID: YsfZ7Rq-WGw33NUn9AFMWEuurzryvzET
CSeq: 40743 MESSAGE
Accept: text/plain, application/im-iscomposing+xml
Proxy-Authorization: Digest username="s-user.03",
realm="sip-dev.example.com", nonce="Y48hMWOPIAW7JeSQ7/a+cuJ1gKwT8hrC",
uri="sip:s-user.02@sip-dev.example.com",
response="3b7c34476443e5f1125fa460a4981180",
cnonce="3AT-ZMwyfpgaMwlulh5cq5vJHi75-wnz", qop=auth, nc=00000001
Content-Type: text/plain
Content-Length: 59
Dec 6 11:57:09 qcast-webserver-dev /usr/sbin/kamailio[15340]: WARNING:
{1 40743 MESSAGE YsfZ7Rq-WGw33NUn9AFMWEuurzryvzET} <core>
[core/forward.c:228]: get_send_socket2(): protocol/port mismatch (forced
tcp:192.168.58.15:15006, to tls:192.168.58.1:60982)
Dec 6 11:57:09 qcast-webserver-dev /usr/sbin/kamailio[15340]: ERROR: {1
40743 MESSAGE YsfZ7Rq-WGw33NUn9AFMWEuurzryvzET} tm [ut.h:315]:
uri2dst2(): no corresponding socket found for "192.168.58.1" af 2
(tls:192.168.58.1:60982)
Dec 6 11:57:09 qcast-webserver-dev /usr/sbin/kamailio[15340]: ERROR: {1
40743 MESSAGE YsfZ7Rq-WGw33NUn9AFMWEuurzryvzET} tm [t_fwd.c:471]:
prepare_new_uac(): can't fwd to af 2, proto 3 (no corresponding
listening socket)
Dec 6 11:57:09 qcast-webserver-dev /usr/sbin/kamailio[15340]: ERROR: {1
40743 MESSAGE YsfZ7Rq-WGw33NUn9AFMWEuurzryvzET} tm [t_fwd.c:1754]:
t_forward_nonack(): failure to add branches
Dec 6 11:57:09 qcast-webserver-dev /usr/sbin/kamailio[15340]: ERROR: {1
40743 MESSAGE YsfZ7Rq-WGw33NUn9AFMWEuurzryvzET} sl [sl_funcs.c:372]:
sl_reply_error(): stateless error reply used: I'm terribly sorry, server
error occurred (7/SL)
based on what we have understood in the message headers "Via" and
Record-Route" there are the right information to reach back the proxy
Edge, but looking to the error message it seems that the kamailio
register try to reach back the proxy edge through the TLS instead of
using the TCP.
Could someone put me in the right direction.
Thanks
Regards
--
------------------------------------------------------------------------
Ing. Giovanni Iamonte
Developments and technologies area
Quintetto Srl
Via Monte Navale, 1
10015 - Ivrea (TO)
mobile: +39 393 9196310
tel: +39 0165 1845290
e-mail: giovanni.iamonte(a)quintetto.it
web: www.quintetto.it
Hi,
I have experienced out of order packet processing when testing a simple Kamailio config.
The configuration is as follows, basically:
request_route{
record_route();
enum_query();
xlog("INVITE ENUM query - To URI $tU");
forward();
}
I saw this thread from 2020:
https://www.mail-archive.com/sr-users@lists.kamailio.org/msg11786.html
The issue seems to be that kamailio process scheduling is naïve – i.e., incoming SIP packets are processed without regard to whether packets received before this one, are currently being processed. This means any packets after the initial INVITE that require more processing, can get reordered.
In my test lab I have:
SIPp – UAC
Kamailio Proxy
SIPp – UAS
The proxy uses enum NAPR lookups to route calls to +13038151000 to the UAS.
Now, if I do SIPp UAC o SIPp UAS directly, I have no problems – no out of order packets.
It is only when I introduce Kamailio in the middle that I get OOO packets.
See the images attached: uac-to-proxy, proxy, and proxy-to-uas.
In this example, Kamailio OOO causes SIPp UAC to fail to “generate audio” – because UAC does not see packets in the correct order, I never turns on the simulated audio. Calls that have in-order dialogs, work fine, and SIPP UAC “pauses” 10 seconds to simulate a phone call.
So far, the error rate runs from 1/1000 to around 1/200 – pretty bad.
In the thread, a few things were suggested.
Have fewer kamailio processes than cores:
Did not resolve issue.
Try route_locks_size = 256
Did not resolve issue. Though, it did alter it somewhat. But, it is not clear to me how this works – would this setting restrict the number of open calls to 256?
Have only one kamailio process: (“children=1”)
This works. “Works”, I should say, because this would greatly restrict total platform scalability to a point where it is probably useless for my application.
I saw the same issue discussed in the OpenSIPS mailing list from 2010, and the response was “this is not a bug”.
Well, I respectfully beg to differ with both OpenSIPS and Kamailio – it IS a bug. I don’t think a proxy should reorder packets involved in a call in a non-deterministic way. In the Kamailio list thread, Alex Balashov discusses the contortions he has to go through to avoid repercussions from this issue.
Kamailio as-is probably works fine for relatively low-volume operations. And a lot of the feedback is “why are out of order packets a problem?” OK, sure, in the very specific example given in the 2020 thread, maybe who cares. But in my thinking, there is absolutely nothing preventing Kamailio from generating much more serious OOO scenarios that would cause calls to fail. In my example, Kamailio OOO causes SIPp to fail to “generate audio”. Who knows how other SIP stacks will behave?
But the more one will try to scale Kamailio, the more significantly this out of order processing issue will become.
The solution to this seems very simple and straightforward – put packets to be processed into a queue PER Call-ID, or something along those lines.
In short, the parallelism should be by call, not by packet.
What say ye? Have I misunderstood something here?
Cheers,
Jawaid
Hello Everyone,
I am using Kamailio sqlops module to write to a remote database which is
not the database of Kamailio. It is working fine. But for redundancy
purpose, if this database goes down, I want the Kamailio to detect the
failure at runtime and write the data to another database (standby
database).
Is it possible? Can anybody please guide me on this asap?
Regards,
Vicky
Hi
On our devevelpment system, we have this dispatcher list:
3200 sip:reg1.dev.example.com:5060 0 0 name="Registrar01";
3200 sip:reg2.dev.example.com:5060 0 0 name="Registrar02";
The names or course are in the DNS: A,AAAA and PTR.
ds_is_from_list() returns the groupId 3200
Now I have started building the production system...
3200 sip:reg1.prod.example.com:5060 0 0 name="Registrar01";
3200 sip:reg2.prod.example.com:5060 0 0 name="Registrar02";
DNS ist set up the same. I have double-checked: Names and IP addresses
do resolve as they should.
ds_is_from_list() returns nothing.
I have also sniffed the connection. The ip addresses in the packets are
the ones I expect.
modparam("dispatcher", "ds_ping_from",
"sip:survivability@sip.example.com")
pings the machines and is getting answers.
What else could cause this not to match?
--
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
______________________________________________________