Hallo,
several telephones send a SIP-multicast SUBSCRIBE message to address 224.0.1.75 if they have no settings-URL configured and receive none over DHCP.
So I configure my kamailio server, to respond to that multicast-request.
But: Although mine is working, I do feel it could be improved, since the NOTIFY packet send out is not quite as it should be …
Here is what I did (the 172.23.56.1 is my voip-vlan-address)
listen=udp:172.23.56.1:5060 advertise 192.168.1.156:5060
listen=udp:192.168.1.156:5060 advertise 192.168.1.156:5060
listen=tcp:127.0.0.1:5060
mcast="eth0"
listen=udp:224.0.1.75:5060
….
if ($Ri == "224.0.1.75"){
if(is_method("SUBSCRIBE")){
xlog("L_INFO", "Received pnp-event from IP $si from User-Agent $hdr(User-Agent) und User $fU\r\n" );
sl_send_reply("200", "OK");
t_uac_send("NOTIFY", "$(ct{s.substr,1,0}{s.striptail,1})", "", "","Subscription-State: terminated;reason=timeout\r\nEvent: $hdr(Event)\r\nContent-Type: application/url\r\nFrom: $fU\r\nTo: $hdr(From)", "http://server.conf/settings-{mac}");
}else {
xlog("L_INFO", "Drop message $rm from pnp-Interface \r\n" );
}
exit;
}
And here are the SIP-packets I see on my server (192.168.1.156) coming from my snom-phone (192.168.1.152).
My problems with the NOTIFY -packets are:
1) How do I set the Via parameters to be the same as in the OK-reply?
2) How do I send out the NOTIFY only via the 192.168.1.156 network interface?
3) May I send out the NOTIFY with the Call-ID from the SUBSCRIBE message? How?
Any help is highly appreciated
Jan-Hendrik
#
U 192.168.1.152:58714 -> 224.0.1.75:5060 #258
SUBSCRIBE sip:MAC%3a0004137120D8@lan SIP/2.0.
Via: SIP/2.0/UDP 192.168.1.152:58714;rport.
From: <sip:MAC%3a0004137120D8@lan>;tag=1750588964.
To: <sip:MAC%3a0004137120D8@lan>.
Call-ID: 1395386659(a)192.168.1.152.
CSeq: 1 SUBSCRIBE.
Event: ua-profile;profile-type="device";vendor="snom";model="snom760";version="8.9.3.80".
Expires: 0.
Accept: application/url.
Contact: <sip:192.168.1.152:58714>.
User-Agent: snom760/8.9.3.80.
Content-Length: 0.
.
#
U 192.168.1.156:5060 -> 192.168.1.152:58714 #259
SIP/2.0 200 OK.
Via: SIP/2.0/UDP 192.168.1.152:58714;rport=58714;received=192.168.1.152.
From: <sip:MAC%3a0004137120D8@lan>;tag=1750588964.
To: <sip:MAC%3a0004137120D8@lan>;tag=fb721cde02dffb6bb099728401306798.2f00.
Call-ID: 1395386659(a)192.168.1.152.
CSeq: 1 SUBSCRIBE.
Server: kamailio (5.2.5 (x86_64/linux)).
Content-Length: 0.
.
#
U 192.168.1.156:5060 -> 192.168.1.152:58714 #260
NOTIFY sip:192.168.1.152:58714 SIP/2.0.
Via: SIP/2.0/UDP 224.0.1.75;branch=z9hG4bKf21c.917eaf36000000000000000000000000.0.
To: <sip:MAC%3a0004137120D8@lan>;tag=1750588964.
From: <MAC%3a0004137120D8>;tag=da567df9df3ac234e43969a051db4641-8cfb.
CSeq: 10 NOTIFY.
Call-ID: 24eaa8de01be1768-70960(a)172.23.56.1.
Max-Forwards: 70.
Content-Length: 33.
User-Agent: kamailio (5.2.5 (x86_64/linux)).
Subscription-State: terminated;reason=timeout.
Event: ua-profile;profile-type="device";vendor="snom";model="snom760";version="8.9.3.80".
Content-Type: application/url.
.
http://server.conf/settings-{mac}
#
U 172.23.56.1:5060 -> 192.168.1.152:58714 #261
NOTIFY sip:192.168.1.152:58714 SIP/2.0.
Via: SIP/2.0/UDP 224.0.1.75;branch=z9hG4bKf21c.917eaf36000000000000000000000000.0.
To: <sip:MAC%3a0004137120D8@lan>;tag=1750588964.
From: <MAC%3a0004137120D8>;tag=da567df9df3ac234e43969a051db4641-8cfb.
CSeq: 10 NOTIFY.
Call-ID: 24eaa8de01be1768-70960(a)172.23.56.1.
Max-Forwards: 70.
Content-Length: 33.
User-Agent: kamailio (5.2.5 (x86_64/linux)).
Subscription-State: terminated;reason=timeout.
Event: ua-profile;profile-type="device";vendor="snom";model="snom760";version="8.9.3.80".
Content-Type: application/url.
.
http://server.conf/settings-{mac}
#
U 172.23.56.1:5060 -> 192.168.1.152:58714 #262
NOTIFY sip:192.168.1.152:58714 SIP/2.0.
Via: SIP/2.0/UDP 224.0.1.75;branch=z9hG4bKf21c.917eaf36000000000000000000000000.0.
To: <sip:MAC%3a0004137120D8@lan>;tag=1750588964.
From: <MAC%3a0004137120D8>;tag=da567df9df3ac234e43969a051db4641-8cfb.
CSeq: 10 NOTIFY.
Call-ID: 24eaa8de01be1768-70960(a)172.23.56.1.
Max-Forwards: 70.
Content-Length: 33.
User-Agent: kamailio (5.2.5 (x86_64/linux)).
Subscription-State: terminated;reason=timeout.
Event: ua-profile;profile-type="device";vendor="snom";model="snom760";version="8.9.3.80".
Content-Type: application/url.
.
http://server.conf/settings-{mac}
#
U 192.168.1.152:58714 -> 224.0.1.75:5060 #263
SUBSCRIBE sip:MAC%3a0004137120D8@lan SIP/2.0.
Via: SIP/2.0/UDP 192.168.1.152:58714;rport.
From: <sip:MAC%3a0004137120D8@lan>;tag=1971605806.
To: <sip:MAC%3a0004137120D8@lan>.
Call-ID: 1846532696(a)192.168.1.152.
CSeq: 1 SUBSCRIBE.
Event: ua-profile;profile-type="device";vendor="snom";model="snom760";version="8.9.3.80".
Expires: 0.
Accept: application/url.
Contact: <sip:192.168.1.152:58714>.
User-Agent: snom760/8.9.3.80.
Content-Length: 0.
.
#
U 192.168.1.156:5060 -> 192.168.1.152:58714 #264
SIP/2.0 200 OK.
Via: SIP/2.0/UDP 192.168.1.152:58714;rport=58714;received=192.168.1.152.
From: <sip:MAC%3a0004137120D8@lan>;tag=1971605806.
To: <sip:MAC%3a0004137120D8@lan>;tag=fb721cde02dffb6bb099728401306798.2f00.
Call-ID: 1846532696(a)192.168.1.152.
CSeq: 1 SUBSCRIBE.
Server: kamailio (5.2.5 (x86_64/linux)).
Content-Length: 0.
.
#
U 192.168.1.156:5060 -> 192.168.1.152:58714 #265
NOTIFY sip:192.168.1.152:58714 SIP/2.0.
Via: SIP/2.0/UDP 224.0.1.75;branch=z9hG4bK201a.063839a4000000000000000000000000.0.
To: <sip:MAC%3a0004137120D8@lan>;tag=1971605806.
From: <MAC%3a0004137120D8>;tag=da567df9df3ac234e43969a051db4641-f31b.
CSeq: 10 NOTIFY.
Call-ID: 24eaa8de01be1768-70963(a)172.23.56.1.
Max-Forwards: 70.
Content-Length: 33.
User-Agent: kamailio (5.2.5 (x86_64/linux)).
Subscription-State: terminated;reason=timeout.
Event: ua-profile;profile-type="device";vendor="snom";model="snom760";version="8.9.3.80".
Content-Type: application/url.
.
http://server.conf/settings-{mac}
#
U 192.168.1.152:58714 -> 192.168.1.156:5060 #266
SIP/2.0 200 Ok.
Via: SIP/2.0/UDP 224.0.1.75;branch=z9hG4bKf21c.917eaf36000000000000000000000000.0;received=192.168.1.156.
From: <MAC:0004137120D8>;tag=da567df9df3ac234e43969a051db4641-8cfb.
To: <sip:MAC%3A0004137120D8@lan>;tag=1750588964.
Call-ID: 24eaa8de01be1768-70960(a)172.23.56.1.
CSeq: 10 NOTIFY.
User-Agent: snom760/8.9.3.80.
Content-Length: 0.
.
#
U 192.168.1.152:58714 -> 192.168.1.156:5060 #267
SIP/2.0 200 Ok.
Via: SIP/2.0/UDP 224.0.1.75;branch=z9hG4bKf21c.917eaf36000000000000000000000000.0;received=192.168.1.156.
From: <MAC:0004137120D8>;tag=da567df9df3ac234e43969a051db4641-8cfb.
To: <sip:MAC%3A0004137120D8@lan>;tag=1750588964.
Call-ID: 24eaa8de01be1768-70960(a)172.23.56.1.
CSeq: 10 NOTIFY.
User-Agent: snom760/8.9.3.80.
Content-Length: 0.
.
#
U 192.168.1.152:58714 -> 192.168.1.156:5060 #268
SIP/2.0 200 Ok.
Via: SIP/2.0/UDP 224.0.1.75;branch=z9hG4bK201a.063839a4000000000000000000000000.0;received=192.168.1.156.
From: <MAC:0004137120D8>;tag=da567df9df3ac234e43969a051db4641-f31b.
To: <sip:MAC%3A0004137120D8@lan>;tag=1971605806.
Call-ID: 24eaa8de01be1768-70963(a)172.23.56.1.
CSeq: 10 NOTIFY.
User-Agent: snom760/8.9.3.80.
Content-Length: 0.
.
Hi,
I am fairly new to Kamailio and had a question regarding how to use
Kamailio to enable Session refresh functionality when Kamailio is acting as
Sip Stateful Proxy.
Kamailio Version used: *5.3.2* with *Call Load based routing* using
the *dispatcher
*module.
* From what i understand from the documentation, Kamailio will probably not
be acting as a session refresher, but Kamailio can tear down the call in
case session refresh is negotiated, between the caller and the callee(via
Kamailio Sip Proxy), and no message exchange happens in the duration set in
Session-Expires header. *Is my understanding correct?*
** *I believe the above functionality is possible by using the *sst* and
*dialog* module. I have set the same according to the documentation but I
keep getting the following error:
"dialog [dlg_handlers.c:681]: *get_dlg_timeout(): invalid AVP value, using
default timeout*"
Can someone share a working example?
* When i tried hardcoding the timeout value by setting the timeout_avp to a
specific value, Kamailio did sense a timeout and hence sent a BYE towards
the caller and the Callee side both(which is what the requirement is),
however, i do see the *dialog is still not cleared* in the "kamcmd
dispatcher.list". Output excerpt below for reference:
[root@CPaaSVM ~]# kamcmd dispatcher.list
{
NRSETS: 1
RECORDS: {
SET: {
ID: 1
TARGETS: {
DEST: {
URI: sip:172.27.44.121:5080
;transport=tcp
FLAGS: AP
PRIORITY: 0
ATTRS: {
BODY:
duid=sample-cas;maxload=1000
DUID: sample-cas
MAXLOAD: 1000
WEIGHT: 0
RWEIGHT: 0
SOCKET:
}
LATENCY: {
AVG: 111.304000
STD: 1042.193000
EST: 2.385000
MAX: 9999
TIMEOUT: 1
}
RUNTIME: {
DLGLOAD: *1*
}
}
}
}
}
}
It is noteworthy that in case the BYE is initiated by either the caller or
the callee, the dialog is cleared properly and the DLGLOAD is set to 0 on
call termination.
Any pointers for the above questions would be highly appreciated.
Regards,
Harneet
--
"Once you eliminate the impossible, whatever remains, no matter how
improbable, must be the truth" - Sir Arthur Conan Doyle
Hi All,
I'm trying to establish a topology with Kamailio which is located between Asterisk and Outside.
My issue is "transaction matching failed" (t_check_trans failed). That means Kamailio does not recognise ACK & BYE message to forwards. I had a check on email list and google but found nothing.
I'm using it with record_route.
SIP signalling and part of kamailio.cfg is below. Is there any suggestion?
route[WITHINDLG] {
if (!has_totag()) return;
if (loose_route()) {
route(DLGURI);
if (is_method("BYE")) {
setflag(FLT_ACC); # do accounting ...
setflag(FLT_ACCFAILED); # ... even if the transaction fails
}
else if ( is_method("ACK") ) {
xlog("ack is came: $si:$sp\n");
route(NATMANAGE);
}
else if ( is_method("NOTIFY") ) {
record_route();
}
route(RELAY);
exit;
}
if (is_method("SUBSCRIBE") && uri == myself) {
route(PRESENCE);
exit;
}
if ( is_method("ACK") ) {
if ( t_check_trans() ) {
route(RELAY);
exit;
} else {
exit;
}
}
sl_send_reply("404","Not here");
exit;
}
route[NATMANAGE] {
#!ifdef WITH_NAT
if (is_request()) {
if(has_totag()) {
if(check_route_param("nat=yes")) {
setbflag(FLB_NATB);
}
}
}
route(RTPPROXY);
if (!(isflagset(FLT_NATS) || isbflagset(FLB_NATB)))
return;
if (is_request()) {
if (!has_totag()) {
if(t_is_branch_route()) {
add_rr_param(";nat=yes");
}
}
}
if (is_reply()) {
if(isbflagset(FLB_NATB)) {
if(is_first_hop())
set_contact_alias();
}
}
#!endif
return;
}
Asterisk > Kamailio
INVITE sip:user@outside_ip SIP/2.0
Via: SIP/2.0/UDP asterisk_ip:5060;branch=z9hG4bK1b56cce0
Max-Forwards: 70
From: "KUYRUK" <sip:0553847<tel:+10553847>aaaa@asterisk_ip>;tag=as3dde7cdb
To: <sip:user@outside_ip>
Contact: <sip:0553847<tel:+10553847>aaaa@asterisk_ip:5060>
Call-ID: 62a480bf71d2a1aa0ec94b454cd98945@asterisk_ip:5060
CSeq: 102 INVITE
User-Agent: Asterisk PBX 1.8.32.3
Kamailio > Outside
INVITE sip:user@outside_ip SIP/2.0
Record-Route: <sip:kamailio_ip;lr;nat=yes>
Via: SIP/2.0/UDP kamailio_ip;branch=z9hG4bK7b3f.8e4716eeea4b0dc45cc51d21b5aded57.0
Via: SIP/2.0/UDP asterisk_ip:5060;rport=5060;branch=z9hG4bK1b56cce0
From: "KUYRUK" <sip:0553847<tel:+10553847>aaaa@asterisk_ip>;tag=as3dde7cdb
To: <sip:user@outside_ip>
Contact: <sip:0553847<tel:+10553847>aaaa@asterisk_ip:5060;alias=asterisk_ip~5060~1>
Call-ID: 62a480bf71d2a1aa0ec94b454cd98945@asterisk_ip:5060
CSeq: 102 INVITE
User-Agent: Asterisk PBX 1.8.32.3
Outside > Kamailio
SIP/2.0 200 OK
Via: SIP/2.0/UDP kamailio_ip;branch=z9hG4bK7b3f.8e4716eeea4b0dc45cc51d21b5aded57.0
Via: SIP/2.0/UDP asterisk_ip:5060;rport=5060;branch=z9hG4bK1b56cce0
From: "KUYRUK" <sip:0553847<tel:+10553847>aaaa@asterisk_ip>;tag=as3dde7cdb
To: <sip:user@outside_ip>;tag=kv8iml6ur9
Call-ID: 62a480bf71d2a1aa0ec94b454cd98945@asterisk_ip:5060
CSeq: 102 INVITE
Record-Route: <sip:kamailio_ip;lr;nat=yes>
Contact: <sip:user@outside_ip:5060;alias=x.x.x.x~18005~6;transport=udp>
Kamailio > Asterisk
SIP/2.0 200 OK
Via: SIP/2.0/UDP asterisk_ip:5060;rport=5060;branch=z9hG4bK1b56cce0
From: "KUYRUK" <sip:0553847<tel:+10553847>aaaa@asterisk_ip>;tag=as3dde7cdb
To: <sip:user@outside_ip>;tag=kv8iml6ur9
Call-ID: 62a480bf71d2a1aa0ec94b454cd98945@asterisk_ip:5060
CSeq: 102 INVITE
Record-Route: <sip:kamailio_ip;lr;nat=yes>
Contact: <sip:user@outside_ip:5060;alias=x.x.x.x~18005~6;transport=udp>
Asterisk > Kamailio THIS ACK IS NOT ROUTED TO OUTSIDE BY KAMAILIO!!
ACK sip:user@outside_ip:5060;alias=x.x.x.x~18005~6;transport=udp SIP/2.0
Via: SIP/2.0/UDP asterisk_ip:5060;branch=z9hG4bK73366924
Route: <sip:kamailio_ip;lr;nat=yes>
From: "KUYRUK" <sip:0553847<tel:+10553847>aaaa@asterisk_ip>;tag=as3dde7cdb
To: <sip:user@outside_ip>;tag=kv8iml6ur9
Contact: <sip:0553847<tel:+10553847>aaaa@asterisk_ip:5060>
Call-ID: 62a480bf71d2a1aa0ec94b454cd98945@asterisk_ip:5060
CSeq: 102 ACK
User-Agent: Asterisk PBX 1.8.32.3
Get Outlook for Android<https://aka.ms/ghei36>
Hi!
Actually I’m trying to get Kamailio to work as MS Teams SBC following by perfect article
https://skalatan.de/en/blog/kamailio-sbc-teams <https://skalatan.de/en/blog/kamailio-sbc-teams>
It works well, but one thing is bothering me.
I’m using Let’sEncrypt certs (actually, works well), but with setting in tls.conf
verify_certificate = yes
require_certificate = yes
It’s giving an errors like
/usr/sbin/kamailio[4551]: ERROR: tls [tls_util.h:42]: tls_err_ret(): TLS write:error:1416F086:SSL routines:tls_process_server_certificate:certificate verify failed
/usr/sbin/kamailio[4551]: ERROR: <core> [core/tcp_read.c:1505]: tcp_read_req(): ERROR: tcp_read_req: error reading - c: 0x7f03e6d23d88 r: 0x7f03e6d23e08 (-1)
They are resolved with setting these settings (verify/require) to off (actually, as mentioned here - https://www.fredposner.com/1836/kamailio-tls-and-letsencrypt/ <https://www.fredposner.com/1836/kamailio-tls-and-letsencrypt/>), but I’m really curious - why?
As I got, it’s using openssl verify on a background, but this check locally passed with
openssl verify -CAfile issuer.crt myserver.crt
myserver.crt: OK
So, is there any tricks to lets encrypt or just some misconfig in tls.cfg?
Now it looks like one from article
[server:default]
method = TLSv1.2+
verify_certificate = yes
require_certificate = yes
private_key = /etc/kamailio/tls/myserver.key
certificate = /etc/kamailio/tls/myserver.crt
ca_list = /etc/kamailio/tls/issuer.crt
[client:default]
method = TLSv1.2+
verify_certificate = yes
require_certificate = yes
private_key = /etc/kamailio/tls/myserver.key
certificate = /etc/kamailio/tls/myserver.crt
ca_list = /etc/kamailio/tls/issuer.crt
—
Regards, Igor
Hi,
With Asterisk, we are able to get some peer round-trip connection statistic by setting qualify=yes for the specified peer.
It sends periodic OPTIONS to the peer and calculates the time round trip time.
It's something like - "Status: OK (30 ms)".
Is there any way to achieve this in Kamailio by using nathelper module, or any other?
Thank you.
Hello,
I have in production environment with 4 proxies using DMQ to sync terminal
registers and the DMQ configuration parameters is following:
loadmodule "dmq.so"
#modparam("dmq", "server_address", "sip:MY_IP_ADDRESS:MY_PORT_ADDRESS")
modparam("dmq", "notification_address", "DMQ_HOSTS")
modparam("dmq", "multi_notify", 1)
modparam("dmq", "num_workers", 4)
In the lab environment with the same configuration that in prod, I can
simulate this problem with 12000 terminal REGISTERS and, when doing several
restarts on a proxy, one of them is generated a coredump.
Analyzing the core, I can see that the problem is concurrency in the dmq
synchronization.
Job_queue_size (...) is called with a valid *queue *and, but inside this
function, the *queue *is null.
(gdb) up
#1 0x00007fefe58ee246 in job_queue_size (queue=0x0) at worker.c:254
254 return atomic_get(&queue->count);
(gdb) print queue
$1 = (job_queue_t *) 0x0
(gdb) up
#2 0x00007fefe58ed920 in add_dmq_job (msg=0x7ff028b453f8,
peer=0x7fefebcc4df8) at worker.c:184
184 if(job_queue_size(workers[i].queue) == 0) {
(gdb) print i
$2 = 1
(gdb) print workers[i].queue
$3 = (job_queue_t *) 0x7fefebce49b0
If I configure DMQ with num_workers=1 I can't reproduce this problem.
I'm using the kamailio 5.0.8 release.
Is this problem known to you? What is the right way to solve it?
Best Regards,
Virgílio Cunha
Hi there,
Question: how can I advertise and later match multiple FQDNs per socket?
Example:
auto_aliases=no
alias="mydomain.net":5060
alias="mydomain.net":5061
alias="client1.mydomain.net":5060
alias="client1.mydomain.net":5061
# looks like I can advertise only one address per socket?
listen=udp:65.65.65.65:5060 advertise "mydomain.net":5060
listen=tls:65.65.65.65:5061 advertise "mydomain.net":5061
Adding RR before relaying downstream like so:
record_route_preset("client1.mydomain.net:5061;transport=tls;r2=on",
"client1.mydomain.net:5060;r2=on");
This is the warning (just warning, works fine otherwise) after receiving
for example the ACK from upstream following the 200 OK:
*WARNING*: {1 19082 ACK } rr [loose.c:768]: rr_do_force_send_socket(): no
socket found to match second RR (sip:client1.mydomain.net:5061
;transport=tls;lr;r2=on)
Figured warning itself can be turned off with modparam
"enable_socket_mismatch_warning" of RR, still I'd like to know if I'm doing
something wrong or there's a better way.
Much obliged,
--Sergiu
Hello there,
I'm facing an issue with kamailio 5.3.2 when it is starting up, it breaks
with signal 11 and generates a coredump file:
- https://pastebin.com/FSqyGFp8
This seems to be something related to dmq module, kamailio exits with
signal 11 when it receives a DMQ notification_peer message.
I did a few more tests and I noticed that problem disappears if I configure
DMQ with one worker only, which takes me to think that it's something
related to concurrency.
Best regards
--
Cumprimentos
José Seabra
In kamailio/etc/kamailio.cfg NAT test is based on nat_uac_test("19").
19 includes test 16:
16 - Test if the source port is different from the port in the “Via”
header. If the “Via” header contains no port, it uses the default SIP
port 5060
Based on a couple of tests using baresip, looks like that results in
false positive when UA connects to SIP proxy via TCP.
An example:
T 2020/03/24 13:57:12.685441 192.26.134.10:38940 -> 192.26.134.1:5060 [AP] #127
REGISTER sip:test.tutpro.com SIP/2.0.
Via: SIP/2.0/TCP 192.26.134.10:44717;branch=z9hG4bK5b6aa423104ef942;rport.
Does someone know why test 16 is included?
-- Juha
