Hello,
I am trying to configure kamailio to use external antifraud protection using so called "traffic loop" when call is forwarded to external SIP proxy that would response even with same INVITE back or with error message if number is fraud.
schema: PBX -> kamailio -> traffic loop -> kamailio -> carrier
Kamailio in second and fourth step is the same.
Issue is that if kamailio receives same INVITE back to I would like to forward to next carrier it is possible, but kamailio struggles with transaction handling.
If ACK message come from PBX, kamailio will correctly forward it to traffic loop but when it comes back, function t_check_trans is failed and I cant relay it. Only workaround is to use send() message, but that causes deny of BYE message from carrier.
My question is following:
Is it possible to register two different transactions states for same message? If yes how? If no, would it help to send and receive messages on another network port or not?
Thank you,
Michal
Hello!
Due to I still experience irregular Kamailio 5.4 crashes (like 1/month)
related to SSL (using websockets and SIPS) I'm wondering, could openSSL
upgrade change the situation?
As of now in CentOS 7 I have 1.0.2k version.
Does anyone have experience to fix crash-related to TLS problems with
openSSL upgrade?
Or maye some tuneup of TCP parameters can help here?My current setup is
quite simple:
children=4
enable_tls=yes
tcp_accept_no_cl=yes
tcp_connection_lifetime=600
tcp_max_connections=998976 # 1000000 - 1024, so we're leaving 1k for system
reserve
tls_max_connections=998976
Number of clients ~ 200 constantly connected to websocket.
--
Best regards,
Igor
HI,
I am facing a problem related to the IMC module.
I have installed kamailio 5.2.x and I tried to list the members of a
room-qsipchat.
In my test environment the kamailio.cfg file it is very basic, the
kamailio server listen on
tcp=192.168.100.192:15006
the client run on a PC with IP address 192.168.100.156
the imc outbound_proxy is set
modparam("imc", "db_url", DBURL)
modparam("imc", "imc_cmd_start_char", "#")
modparam("imc", "outbound_proxy",
"sip:sip-test.quintetto.it:15006;transport=tcp")
The client start by sending a #join message to kamailio and looking the
log file I can see that the room-qsipchat has been create, and also I
received the message 200 OK.
By using the tcpdump I can see the join message from the Client to
kamailio server and the reply from kamailio to the client.
When I send the #list message to the room-qsipchat , I expecting to
receive the message relate to room's members and the 200 OK message.
When I tcp dumping I saw the following messages
********************************************************************
Request from client to list the members - from client to server
********************************************************************
TX 538 bytes Request msg MESSAGE/cseq=57652 (tdta0x77b26460a8) to TCP
192.168.100.192:15006:
MESSAGE sip:room-qsipchat@sip-test.quintetto.it SIP/2.0
Via: SIP/2.0/TCP
192.168.100.156:48129;rport;branch=z9hG4bKPjRzgOBgY6vfKZ8Fh8GA4CWheCO840Xzud;alias
Max-Forwards: 70
From:
<sip:quintetto00@sip-test.quintetto.it>;tag=1is.Ng6ZKJmCT1uAJ9WuJhe3hiQysj9f
To: <sip:room-qsipchat@sip-test.quintetto.it>
Call-ID: GwOQMLFfIq7o7jvF4OQlJ-jBb2OBaAKY
CSeq: 57652 MESSAGE
Accept: text/plain, application/im-iscomposing+xml
Route: <sip:sip-test.quintetto.it:15006;transport=tcp;lr>
Content-Type: text/plain
Content-Length: 5
#list
********************************************************************
The server ask for the authentication - from server to client
********************************************************************
2022-10-17 15:45:25.837 4700-10610/it.quintetto.qsipchat
D/pjlib(pjsua_1): RX 574 bytes Response msg 407/MESSAGE/cseq=57652
(rdata0x77b3337330) from TCP 192.168.100.192:15006:
SIP/2.0 407 Proxy Authentication Required
Via: SIP/2.0/TCP
192.168.100.156:48129;rport=48129;branch=z9hG4bKPjRzgOBgY6vfKZ8Fh8GA4CWheCO840Xzud;alias;received=192.168.100.156
From:
<sip:quintetto00@sip-test.quintetto.it>;tag=1is.Ng6ZKJmCT1uAJ9WuJhe3hiQysj9f
To:
<sip:room-qsipchat@sip-test.quintetto.it>;tag=1e5fbdd4b14eff95c400342f4634da91.e417
Call-ID: GwOQMLFfIq7o7jvF4OQlJ-jBb2OBaAKY
CSeq: 57652 MESSAGE
Proxy-Authenticate: Digest realm="sip-test.quintetto.it",
nonce="Y01doWNNXHVEyRtiAyN28xJdMjNIG8Ju"
Server: kamailio (5.2.8 (x86_64/linux))
Content-Length: 0
*********************************************************************
The client send the authenticated request - from client to server
********************************************************************
TX 755 bytes Request msg MESSAGE/cseq=57653 (tdta0x77b26460a8) to TCP
192.168.100.192:15006:
MESSAGE sip:room-qsipchat@sip-test.quintetto.it SIP/2.0
Via: SIP/2.0/TCP
192.168.100.156:48129;rport;branch=z9hG4bKPjj6uuy25r0kKlnICHKQWEaIweOex-sNyq;alias
Max-Forwards: 70
From:
<sip:quintetto00@sip-test.quintetto.it>;tag=1is.Ng6ZKJmCT1uAJ9WuJhe3hiQysj9f
To: <sip:room-qsipchat@sip-test.quintetto.it>
Call-ID: GwOQMLFfIq7o7jvF4OQlJ-jBb2OBaAKY
CSeq: 57653 MESSAGE
Accept: text/plain, application/im-iscomposing+xml
Route: <sip:sip-test.quintetto.it:15006;transport=tcp;lr>
Proxy-Authorization: Digest username="quintetto00",
realm="sip-test.quintetto.it", nonce="Y01doWNNXHVEyRtiAyN28xJdMjNIG8Ju",
uri="sip:room-qsipchat@sip-test.quintetto.it",
response="d495ec20cb1be8f1b605d4e5b1a4c357"
Content-Type: text/plain
Content-Length: 5
#list
**************************************************************************
The server send the 200 OK message - from server to client
********************************************************************
RX 447 bytes Response msg 200/MESSAGE/cseq=57653 (rdata0x77b3337330)
from TCP 192.168.100.192:15006:
SIP/2.0 200 ok
Via: SIP/2.0/TCP
192.168.100.156:48129;rport=48129;branch=z9hG4bKPjj6uuy25r0kKlnICHKQWEaIweOex-sNyq;alias;received=192.168.100.156
From:
<sip:quintetto00@sip-test.quintetto.it>;tag=1is.Ng6ZKJmCT1uAJ9WuJhe3hiQysj9f
To:
<sip:room-qsipchat@sip-test.quintetto.it>;tag=1e5fbdd4b14eff95c400342f4634da91.365f
Call-ID: GwOQMLFfIq7o7jvF4OQlJ-jBb2OBaAKY
CSeq: 57653 MESSAGE
Server: kamailio (5.2.8 (x86_64/linux))
Content-Length: 0
*********************************************************************************
Till here everything is OK.
But regarding the members when a TCP dumping I saw a message with the
room's members
that go from the kamailio server to the kamailio server
*********************************************************************************
MESSAGE sip:quintetto00@sip-test.quintetto.it SIP/2.0
Via: SIP/2.0/TCP
192.168.100.192:15006;branch=z9hG4bKf20a.be253b92000000000000000000000000.0
To: <sip:quintetto00@sip-test.quintetto.it>
From:
<sip:room-qsipchat@sip-test.quintetto.it>;tag=03e4c67b0f95c0aeb1f633479b4aa5cd-72f2
CSeq: 10 MESSAGE
Call-ID: 37db44aa523ea24a-6567(a)192.168.100.192
Max-Forwards:.70
Content-Length: 47
User-Agent: kamailio (5.2.8 (x86_64/linux))
Content-Type: text/plain
Members:
*sip:quintetto00@sip-test.quintetto.it
**************************************************************************************
a reply from the kamailio server to the kamailio server, with an
authenticated request
**************************************************************************************
SIP/2.0.407.Proxy Authentication.Required
Via: SIP/2.0/TCP
192.168.100.192:15006;branch=z9hG4bKf20a.be253b92000000000000000000000000.0
To:
<sip:quintetto00@sip-test.quintetto.it>;tag=1e5fbdd4b14eff95c400342f4634da91.cfc3
From:
<sip:room-qsipchat@sip-test.quintetto.it>;tag=03e4c67b0f95c0aeb1f633479b4aa5cd-72f2
CSeq: 10 MESSAGE
Call-ID: 37db44aa523ea24a-6567(a)192.168.100.192
Proxy-Authenticate: Digest realm="sip-test.quintetto.it",
nonce="Y01fQmNNXhbsHdM1THmENyJn1MH/VD/8"
Server: kamailio (5.2.8 (x86_64/linux))
Content-Length:.0
**************************************************************************************
bottom of line the outbound_proxy request for an authenticated request,
but kamailio do not reply to this request.
Could you please point me in the right direction?
Thanks a lot for any help.
Bye
--
------------------------------------------------------------------------
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 sr-users,
Since ClueCon is going on right now, and some Kamailio community members
are involved I hope you will forgive a little promo here: I have a RHEL8
build of the just released 1.10.8 on Copr:
https://copr.fedorainfracloud.org/coprs/beaveryoga/FreeSWITCH-1.10.8/
Hope you will find it useful in your kamailio + Class 5 scenarios!
Cheers
Shih-Ping
Hello,
as I am not a user of dialog variables, I am turning to community to ask
for help testing the current master branch with configurations that make
use of dialog variables and acc dialog-based cdr generation.
With a few reports of issues related to dialog modules and unexpected
crashes, I looked over the code and noticed that the access of the value
for dialog variables was not protected, making them vulnerable of
invalid memory access in case of the variable was updated by another
process or dialog was terminated.
I introduced a couple of new functions to try to cover different use
cases of getting the dlg variable values, dialog management code was not
affected, but given that these commits need to be backported to stable
branch (5.6), I want to get proper feedback from community that things
work fine.
A previous attempt of a simpler fix was not enough, having side effects
to acc module for dialog-based cdr generation, because it was keeping
referenced to many dlg variables at the same time.
In short, it would be appreciated any feedback on testing dialog and acc
with dialog-based cdr generation using git master branch.
Cheers,
Daniel
--
Daniel-Constantin Mierla -- www.asipto.comwww.twitter.com/miconda -- www.linkedin.com/in/miconda
Kamailio Advanced Training - Online
Nov 7-10, 2022 (Europe Timezone)
* https://www.asipto.com/sw/kamailio-advanced-training-online/
Hi
Looking for advise if anyone could point out where im going wrong.
My setup is Kamailio Ver 5.6.0 running in azure , rtpengine Version: git-master-dc395d5, behind kamailio I have asterisk ver 18.12.1
Kamailio conf I have interface set as below
listen=udp:10.3.1.6:5060 advertise WANIP:5060
and rtpengine.conf set as below
interface = eth0/10.3.1.5
but when I can make a call I don't get any audio, rtpengine.log extract below shows that rtp is going to the private IP rather that the Public IP of the phone that initiated the call, do I need to set rtpengine_manage() to fix this?
Oct 7 09:38:58 kamailio-proxy rtpengine[8127]: INFO: [NmE0MjdhMzA4NjUzYWVjMmRjYzIxNGJjMTY4ZTc2MWE. port 30278]: [core] Confirmed peer address as 10.3.1.5:12890
Oct 7 09:38:58 kamailio-proxy rtpengine[8127]: INFO: [NmE0MjdhMzA4NjUzYWVjMmRjYzIxNGJjMTY4ZTc2MWE. port 30278]: [core] Kernelizing media stream: 10.3.1.5:12890 -> 10.3.1.6:30278 | 10.3.1.6:30298 -> 192.168.0.123:40042
Oct 7 09:39:00 kamailio-proxy rtpengine[8127]: INFO: [NmE0MjdhMzA4NjUzYWVjMmRjYzIxNGJjMTY4ZTc2MWE. port 30279]: [core] Confirmed peer address as 10.3.1.5:12891
Kind regards
gerry
Gerry Kernan | Technical Director
Mobile: +353(0)86-170 9790
[Graphical user interface, website Description automatically generated]<https://www.infinityit.ie/>
[A picture containing text, clipart Description automatically generated,Icon Description automatically generated]
Since on the topic of tsilo:
1. I watched Federico’s presentation on it from 2015, and his examples insinuate that it is necessary to store the index and label of a suspended transaction in some external vehicle, e.g. htable, for use with ts_append_to(). Why would one do this when it is possible to call ts_append() based on R-URI alone?
2. The appropriate pattern of interaction between tsilo and http_async_client — which I imagine to be a rather common use-case — is rather unclear.
If I use http_async_query() to call out to a PN service, with $http_req(suspend) = 1, what should happen to the current instance of SIP request processing?
That is to say:
request_route {
. . .
t_check_trans();
if(is_method(“REGISTER”)) {
. . .
save(“location”, “0x06”);
if(ts_append(“location”, “$tu”)) {
xlog(“success”);
}
return;
}
else if(is_method(“INVITE”)) {
# PN stuff.
ts_store(“$var(uri)”);
http_async_query(“http://url”, “PUSH_REPLY”);
return; # <— ???
}
}
route[HTTP_PUSH_REPLY] {
. . .
if(!t_relay())
sl_reply_error();
}
I should add that this proxy front-ends a registrar, but is not in itself a registrar. It contains a shadow registrar - hence the save() calls - in order to be able to take advantage of the ’tsilo’ module, given its dependency on registrar/usrloc.
This leads to the difference that the gateway receives requests with RURIs that have already been resolved to a contact binding elsewhere, so there are no lookup() calls. How should this play into the http_async_client workflow?
Appreciate any help!
— Alex
--
Alex Balashov | Principal | Evariste Systems LLC
Tel: +1-706-510-6800 / +1-800-250-5920 (toll-free)
Web: http://www.evaristesys.com/, http://www.csrpswitch.com/
Hi,
When there are no stored transactions for an AOR, it logs this error:
Oct 13 07:48:18 gw1 /usr/sbin/kamailio[14758]: ERROR: tsilo [ts_append.c:64]: ts_append(): failed to retrieve record for sip:abalashov@sip.evaristesys.com
But not having transactions ts_store()’d is a rather normal occurrence, right? It is the expected case the vast majority of the time that someone registers.
Does that mean one is simply destined to have this scary-looking error, to the syslog ERROR facility, for a normal runtime condition? Is there not some principle against using attention-grabbing error messages this way? Would a patch to fix be welcome?
— Alex
--
Alex Balashov | Principal | Evariste Systems LLC
Tel: +1-706-510-6800 / +1-800-250-5920 (toll-free)
Web: http://www.evaristesys.com/, http://www.csrpswitch.com/
Hi Sir/Mada,
I'm trying to integrate kamailio + freeswitch, according to the manual http://kb.asipto.com/freeswitch:kamailio-3.3.x-freeswitch-1.2.x-sbc on Kamailio v5.6
modified the kamailio.cfg file, add WITH_FREESWITCH parts, then kamailio could NOT start up.
Could you please help check, what should be modified to fit the version 5.6？
Thanks！
BR，
Sparkle Zou
> The duration of the media playback is returned from the play_media()
> command (see `media_duration` modparam). You could use some sort of
> timer to invoke media unblocking after media playback ends. Sadly my
> Kamailio-Fu isn't strong enough to be able to tell you how to run this
> sort of timer. :)
>
> Cheers
Thank you for the hint.
I was thinking about timers, but rtimer cannot be triggered in an event
route. I used a "timer" module, it could trigger another route from the
event route but when a new route is triggered unblock_media() is not
aware of the call-id and if i assign call-id to a variable in the event
route, that variable is unavailable at new route. Hope that make sense.
here is my peace of code:
loadmodule "timer.so"
modparam("timer", "declare_timer", "PB_TIMER=START,5000");
route[START]{
xlog("current call id at event route is $ci, but call-id avp is
$avp(call_id)");
unblock_media("all");
timer_enable("PB_TIMER",0); #we need to disable timer or it will be
triggered over and over again
}
event_route[dialog:start]{
xlog("L_INFO", "dialog started, received 200OK");
#block_media();
play_media("all file=/usr/local/src/myfile.wav");
$avp(call_id)=$ci;
timer_enable("PB_TIMER",1);
}
