Added enable_register_publish parameter to enable REGISTER and PUBLISH method for topos
If set to 1 REGISTER and PUBLISH will be enabled for topos Currently only via header will be applied for topos and if mask_callid is set to 1 call-ID will be masked. Other headers should be manged by the user as required.
<!-- Kamailio Pull Request Template -->
<!--
IMPORTANT:
- for detailed contributing guidelines, read:
https://github.com/kamailio/kamailio/blob/master/.github/CONTRIBUTING.md
- pull requests must be done to master branch, unless they are backports
of fixes from master branch to a stable branch
- backports to stable branches must be done with 'git cherry-pick -x ...'
- code is contributed under BSD for core and main components (tm, sl, auth, tls)
- code is contributed GPLv2 or a compatible license for the other components
- GPL code is contributed with OpenSSL licensing exception
-->
#### Pre-Submission Checklist
<!-- Go over all points below, and after creating the PR, tick all the checkboxes that apply -->
<!-- All points should be verified, otherwise, read the CONTRIBUTING guidelines from above-->
<!-- If you're unsure about any of these, don't hesitate to ask on sr-dev mailing list -->
- [x] Commit message has the format required by CONTRIBUTING guide
- [x] Commits are split per component (core, individual modules, libs, utils, ...)
- [ ] Each component has a single commit (if not, squash them into one commit)
- [ ] No commits to README files for modules (changes must be done to docbook files
in `doc/` subfolder, the README file is autogenerated)
#### Type Of Change
- [ ] Small bug fix (non-breaking change which fixes an issue)
- [ ] New feature (non-breaking change which adds new functionality)
- [ ] Breaking change (fix or feature that would change existing functionality)
#### Checklist:
<!-- Go over all points below, and after creating the PR, tick the checkboxes that apply -->
- [ ] PR should be backported to stable branches
- [ ] Tested changes locally
- [ ] Related to issue #XXXX (replace XXXX with an open issue number)
#### Description
<!-- Describe your changes in detail -->
You can view, comment on, or merge this pull request online at:
https://github.com/kamailio/kamailio/pull/3766
-- Commit Summary --
* add enable_register_publish
-- File Changes --
M src/modules/topos/topos_mod.c (2)
M src/modules/topos/tps_msg.c (132)
M src/modules/topos/tps_msg.h (2)
M src/modules/topos/tps_storage.c (6)
-- Patch Links --
https://github.com/kamailio/kamailio/pull/3766.patchhttps://github.com/kamailio/kamailio/pull/3766.diff
--
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/pull/3766
You are receiving this because you are subscribed to this thread.
Message ID: <kamailio/kamailio/pull/3766(a)github.com>
Hi There,
We found a situation where topos seems to break, let me explain... Assuming the following scenario:
```
Caller ---- Callee
A: ------INVITE-----> Record-Route:A.A.A.A, Record-Route:B.B.B.B
B: <-----200 OK------
C: <-----INVITE------ Route: A.A.A.A, B.B.B.B
D: ------200 OK-----> Record-Route:B.B.B.B, Record-Route:A.A.A.A (reversed order)
E: <======INVITE===== Route: B.B.B.B, A.A.A.A (wrong)
```
A and B establish the connection from caller to callee, and topos works fine.
C (re-INVITE from callee) sends the Route header according to the Record-Routes from the original INVITE (A)
D is the 200 OK sent from the caller to the first re-INVITE (C) coming from the callee, with the Record-Route headers reversed, because is the order in which the callee received them; and according to the RFC it's working as intended:
```
When a UAS responds to a request with a response that establishes a
dialog (such as a 2xx to INVITE), the UAS MUST copy all Record-Route
header field values from the request into the response (including the
URIs, URI parameters, and any Record-Route header field parameters,
whether they are known or unknown to the UAS) and MUST maintain the
order of those values.
[...]
[When a UAC receives a response...]
The route set MUST be set to the list of URIs in the Record-Route
header field from the response, taken in reverse order and preserving
all URI parameters.
```
E takes the Route order from the last 200 OK ignoring they are in reversed order and assuming the top one is the first one, when it should be the other way around, sending to an IP address not reachable from the callee. And I think here is the issue, topos should not update the path on the Record-Routes from a 200 OK but if it does, it should take the reverse order
When disabling topos, everything works fine, or with topos enabled, by setting rr_update=0 works for us, but what if there is a real path update, rr_update=0 wouldn't work for us anymore. The Kamailio version is 5.8.0-rc0
Let me know if you need more information.
Thanks a lot,
Javi
--
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/issues/3778
You are receiving this because you are subscribed to this thread.
Message ID: <kamailio/kamailio/issues/3778(a)github.com>
Hello all
we are seeing these kind of logs in a Debian GNU/Linux 11 using kamailio 5.5.6
```Sep 21 17:41:13 lax-dedge-1 /usr/local/kamailio/sbin/kamailio[3155702]: ERROR: <core> [core/forward.c:183]: get_out_socket(): no corresponding socket found for(udp:[164.152.22.248:5060](http://164.152.22.248:5060/))
Sep 21 17:41:13 lax-dedge-1 /usr/local/kamailio/sbin/kamailio[3155698]: ERROR: <core> [core/forward.c:183]: get_out_socket(): no corresponding socket found for(udp:[208.74.138.184:5060](http://208.74.138.184:5060/))
Sep 21 17:41:13 lax-dedge-1 /usr/local/kamailio/sbin/kamailio[3155695]: ERROR: <core> [core/forward.c:183]: get_out_socket(): no corresponding socket found for(udp:[208.74.138.181:5060](http://208.74.138.181:5060/))
Sep 21 17:41:14 lax-dedge-1 /usr/local/kamailio/sbin/kamailio[3155693]: ERROR: <core> [core/forward.c:183]: get_out_socket(): no corresponding socket found for(udp:[38.102.250.60:5060](http://38.102.250.60:5060/))
Sep 21 17:41:14 lax-dedge-1 /usr/local/kamailio/sbin/kamailio[3155707]: ERROR: <core> [core/forward.c:183]: get_out_socket(): no corresponding socket found for(udp:[87.1.1.27:5060](http://87.1.1.27:5060/))
Sep 21 17:41:14 lax-dedge-1 /usr/local/kamailio/sbin/kamailio[3155707]: ERROR: tm [ut.h:302]: uri2dst2(): no corresponding socket for "87.1.1.27" af 2
Sep 21 17:41:14 lax-dedge-1 /usr/local/kamailio/sbin/kamailio[3155707]: ERROR: tm [t_fwd.c:470]: prepare_new_uac(): can't fwd to af 2, proto 1 (no corresponding listening socket)
Sep 21 17:41:14 lax-dedge-1 /usr/local/kamailio/sbin/kamailio[3155697]: ERROR: <core> [core/forward.c:183]: get_out_socket(): no corresponding socket found for(udp:[208.74.138.184:5060](http://208.74.138.184:5060/))
Sep 21 17:41:14 lax-dedge-1 /usr/local/kamailio/sbin/kamailio[3155694]: ERROR: <core> [core/forward.c:183]: get_out_socket(): no corresponding socket found for(udp:[192.40.216.97:5060](http://192.40.216.97:5060/))
Sep 21 17:41:14 lax-dedge-1 /usr/local/kamailio/sbin/kamailio[3155694]: ERROR: <core> [core/forward.c:183]: get_out_socket(): no corresponding socket found for(udp:[208.74.138.180:5060](http://208.74.138.180:5060/))
Sep 21 17:41:14 lax-dedge-1 /usr/local/kamailio/sbin/kamailio[3155714]: ERROR: <core> [core/forward.c:183]: get_out_socket(): no corresponding socket found for(udp:[87.1.1.27:5060](http://87.1.1.27:5060/))
```
The kamailio instance we are using is receiving around 1500 calls per second in average when we do start seeing these errors more frequently
In this instance we are using multihomed
the listen address list is
``` children=14
socket_workers=1
listen=udp:[192.168.99.70:5081](http://192.168.99.70:5081/)
listen=udp:[192.168.99.81:5060](http://192.168.99.81:5060/)
listen=udp:[87.1.1.27:5060](http://87.1.1.27:5060/)
listen=tcp:[192.168.96.105:8095](http://192.168.96.105:8095/)
listen=tcp:[87.1.1.27:5060](http://87.1.1.27:5060/)
tcp_children=6
port=5060
```
We use the first worker only to perform the OPTIONS requests from the dispatcher module.
The sockets
listen=udp:[192.168.99.81:5060](http://192.168.99.81:5060/)
listen=udp:[87.1.1.27:5060](http://87.1.1.27:5060/)
are used to communicate both A and B legs
so when a message is received at [192.168.99.81:5060](http://192.168.99.81:5060/) we send it to [87.1.1.27:5060](http://87.1.1.27:5060/) and viceversa
We were using $fs variable before doing the t_relay() function.
This way is working, but when load increases, seems sometimes kamailio doesn't get the proper socket to forward the reply.
I think the errors mainly are related to responses which are being forwarded, like if the function get_sock_info_list was not able to retrieve the listen interfaces
we have tried to set in the onreply routes the commands
set_recv_socket("udp:[192.168.99.81:5060](http://192.168.99.81:5060/)");
set_send_socket("udp:[87.1.1.27:5060](http://87.1.1.27:5060/)"); (when reply goes from private to public domain)
and it seems it reduces the number of
```
Sep 21 17:41:13 lax-dedge-1 /usr/local/kamailio/sbin/kamailio[3155702]: ERROR: <core> [core/forward.c:183]: get_out_socket(): no corresponding socket found for(udp:[164.152.22.248:5060](http://164.152.22.248:5060/))
Sep 21 17:41:13 lax-dedge-1 /usr/local/kamailio/sbin/kamailio[3155698]: ERROR: <core> [core/forward.c:183]: get_out_socket(): no corresponding socket found for(udp:[208.74.138.184:5060](http://208.74.138.184:5060/))
Sep 21 17:41:13 lax-dedge-1 /usr/local/kamailio/sbin/kamailio[3155695]: ERROR: <core> [core/forward.c:183]: get_out_socket(): no corresponding socket found for(udp:[208.74.138.181:5060](http://208.74.138.181:5060/))
Sep 21 17:41:14 lax-dedge-1 /usr/local/kamailio/sbin/kamailio[3155693]: ERROR: <core> [core/forward.c:183]: get_out_socket(): no corresponding socket found for(udp:[38.102.250.60:5060](http://38.102.250.60:5060/))
errors
```
But i honestly don't know why the
```Sep 21 17:41:14 lax-dedge-1 /usr/local/kamailio/sbin/kamailio[3155707]: ERROR: tm [ut.h:302]: uri2dst2(): no corresponding socket for "87.1.1.27" af 2
Sep 21 17:41:14 lax-dedge-1 /usr/local/kamailio/sbin/kamailio[3155707]: ERROR: tm [t_fwd.c:470]: prepare_new_uac(): can't fwd to af 2, proto 1 (no corresponding listening socket)
appear
```
We also tried to increase the kernel buffers rmem and wmem from 208KB (as we had by default) to 4MB
Do you know a reason which could cause these logs to appear?
Any setup that could mitigate them?
thanks a lot and regards
david escartin
--
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/issues/3583
You are receiving this because you are subscribed to this thread.
Message ID: <kamailio/kamailio/issues/3583(a)github.com>
From the build log
```
CC (gcc) [M kazoo.so] kazoo.o
CC (gcc) [M kazoo.so] kz_amqp.o
kz_amqp.c: In function 'kz_amqp_connection_open_ssl':
kz_amqp.c:857:17: warning: 'amqp_set_initialize_ssl_library' is deprecated [-Wdeprecated-declarations]
857 | amqp_set_initialize_ssl_library(1);
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
In file included from kz_amqp.c:37:
/usr/include/rabbitmq-c/ssl_socket.h:233:16: note: declared here
233 | void AMQP_CALL amqp_set_initialize_ssl_library(amqp_boolean_t do_initialize);
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
CC (gcc) [M kazoo.so] kz_fixup.o
CC (gcc) [M kazoo.so] kz_hash.o
```
Functions description in the header file
https://github.com/alanxz/rabbitmq-c/blob/v0.13.0/include/rabbitmq-c/ssl_so…
```
/**
* Sets whether rabbitmq-c will initialize OpenSSL.
*
* \deprecated Since v0.13.0 this is a no-op. OpenSSL automatically manages
* library initialization and uninitialization.
*
* OpenSSL requires a one-time initialization across a whole program, this sets
* whether or not rabbitmq-c will initialize the SSL library when the first call
* to amqp_ssl_socket_new() is made. You should call this function with
* do_init = 0 if the underlying SSL library is initialized somewhere else
* the program.
*
* Failing to initialize or double initialization of the SSL library will
* result in undefined behavior
*
* By default rabbitmq-c will initialize the underlying SSL library.
*
* NOTE: calling this function after the first socket has been opened with
* amqp_open_socket() will not have any effect.
*
* \param [in] do_initialize If 0 rabbitmq-c will not initialize the SSL
* library, otherwise rabbitmq-c will initialize the
* SSL library
*
* \since v0.4.0
*/
```
--
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/issues/3466
You are receiving this because you are subscribed to this thread.
Message ID: <kamailio/kamailio/issues/3466(a)github.com>
When relaying this `200 OK` repeatedly with calls to `rtpengine_answer()` failing because all RTPEngines in a set are unreachable...
```
Dec 8 06:24:38 gw kamailio[4823]: ERROR: rtpengine [rtpengine.c:2960]: select_rtpp_node(): rtpengine failed to select new for calllen=36 callid=8279a4ea-151e-48de-a23c-5840104126de
```
```
SIP/2.0 200 OK
v:SIP/2.0/UDP 10.150.20.20;branch=z9hG4bK03e.e4da444e627bb575ef4f46151729a1fa.0,SIP/2.0/UDP 10.151.20.108;received=10.151.20.108;rport=5060;branch=z9hG4bKKQyrBKpp04X0K
Record-Route:<sip:10.150.20.20;lr;ftag=emHm2apy95jFe;rtp_relay=1;rtp_group=0>
f:"14045551212"<sip:14045551212@10.151.20.108>;tag=emHm2apy95jFe
t:<sip:16782001111@internal.evaristesys.com>;tag=tHQt0rDcF7UHK
i:8279a4ea-151e-48de-a23c-5840104126de
CSeq:60686471 INVITE
m:<sip:16782001111@10.160.10.55:5060;transport=udp>
User-Agent:VoiceAppServer
Allow:INVITE,ACK,BYE,CANCEL,OPTIONS,MESSAGE,INFO,UPDATE,REFER,NOTIFY
k:path,replaces
u:talk,hold,conference,refer
c:application/sdp
Content-Disposition:session
l:257
v=0
o=DM 1670428117 1670428118 IN IP4 10.160.10.55
s=DM
c=IN IP4 10.160.10.55
t=0 0
m=audio 52418 RTP/AVP 0 101
a=rtpmap:0 PCMU/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=ptime:20
a=rtcp:52419 IN IP4 10.160.10.55
```
Repeat INVITEs eventually result in a crash. This backtrace is taken from a different server but identical scenario:
```
#0 t_should_relay_response (Trans=0x7f4aee56ba80, new_code=200, branch=0, should_store=0x7ffd8b8bbba0, should_relay=0x7ffd8b8bbba4, cancel_data=0x7ffd8b8bbe40,
reply=0x7f4afe40df70) at t_reply.c:1285
1285 && !(inv_through && Trans->uac[branch].last_received<300)) {
Missing separate debuginfos, use: debuginfo-install glibc-2.12-1.192.el6.x86_64 jansson-2.11-1.el6.x86_64 keyutils-libs-1.4-5.el6.x86_64 krb5-libs-1.10.3-57.el6.x86_64 libcom_err-1.41.12-22.el6.x86_64 libev-4.03-3.el6.x86_64 libselinux-2.0.94-7.el6.x86_64 libunistring-0.9.3-5.el6.x86_64 openssl-1.0.1e-48.el6_8.3.x86_64 sqlite-3.6.20-1.el6_7.2.x86_64 zlib-1.2.3-29.el6.x86_64
(gdb) where
#0 t_should_relay_response (Trans=0x7f4aee56ba80, new_code=200, branch=0, should_store=0x7ffd8b8bbba0, should_relay=0x7ffd8b8bbba4, cancel_data=0x7ffd8b8bbe40,
reply=0x7f4afe40df70) at t_reply.c:1285
#1 0x00007f4afd73ab7d in relay_reply (t=0x7f4aee56ba80, p_msg=0x7f4afe40df70, branch=0, msg_status=200, cancel_data=0x7ffd8b8bbe40, do_put_on_wait=1)
at t_reply.c:1821
#2 0x00007f4afd740c38 in reply_received (p_msg=0x7f4afe40df70) at t_reply.c:2558
#3 0x00000000004b5d6a in do_forward_reply (msg=0x7f4afe40df70, mode=0) at core/forward.c:747
#4 0x00000000004b78c9 in forward_reply (msg=0x7f4afe40df70) at core/forward.c:852
#5 0x000000000054982b in receive_msg (
buf=0xb27700 "SIP/2.0 200 OK\r\nv:SIP/2.0/UDP xxx;branch=z9hG4bK9915.dcfe6d03cb21e6c94a6705adb095c566.0,SIP/2.0/UDP xxx;received=xxx;rport=5060;branch=z9hG4bKZmZp0NZv3FvQB\r\nRecord-Rout"..., len=984, rcv_info=0x7ffd8b8bc6c0) at core/receive.c:434
#6 0x00000000006658ca in udp_rcv_loop () at core/udp_server.c:541
#7 0x000000000042500f in main_loop () at main.c:1655
#8 0x000000000042c5bb in main (argc=11, argv=0x7ffd8b8bcc88) at main.c:2696
```
Looks like in the crash frame, `Trans->uac` is `NULL`:
```
(gdb) frame 0
#0 t_should_relay_response (Trans=0x7f4aee56ba80, new_code=200, branch=0, should_store=0x7ffd8b8bbba0, should_relay=0x7ffd8b8bbba4, cancel_data=0x7ffd8b8bbe40,
reply=0x7f4afe40df70) at t_reply.c:1285
1285 && !(inv_through && Trans->uac[branch].last_received<300)) {
(gdb) print Trans->uac
$1 = (struct ua_client *) 0x0
```
I have seen this crash from time to time, though it is infrequent. It always seems to occur when there are problems reaching RTPEngine in a timely fashion.
This is on Kamailio 5.2.4:de9a03, which I know has long fallen off the back of the maintenance train. However, line 1386 of `t_reply.c` in `master:HEAD` shows that the code is no different now:
https://github.com/kamailio/kamailio/blob/master/src/modules/tm/t_reply.c#L…
Of course, it's possible that something upstream has changed so as to prevent this state. Otherwise, I suppose a null pointer safety check for `Trans->uac` is recommended. I'd be happy to submit a patch, just wasn't sure if the feeling was more that this should be resolved higher up the call stack.
--
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/issues/3297
You are receiving this because you are subscribed to this thread.
Message ID: <kamailio/kamailio/issues/3297(a)github.com>
Hi
there is an issue with the SIP parser for the t_uac_send function
https://www.kamailio.org/docs/modules/devel/modules/tm.html#tm.f.t_uac_send
If I call this function for example:
t_uac_send("INVITE", "sip:test@123.123.123.123:5060", "", "" ,"Content-Type: text/plain\r\nContact: <sip:85951b3d-096c-95d6-5f05-4f38095aca9f@172.17.64.120:5060;transport=tcp>;+u.sip!devicename.ccm.cisco.com=\"SEP5486BC7F2BBC\"", "Testbody")
Then the resulting request is broken - it's probably due to a character (exclamation mark?) in the Contact header.... I tested it with a call from kemi, but it probably also occurs when you run it with a normal kamailio -script tests
--
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/issues/3682
You are receiving this because you are subscribed to this thread.
Message ID: <kamailio/kamailio/issues/3682(a)github.com>
Situation: Two Kamailio nodes syncing dialog profiles via DMQ
Observation: When a dialog timeout is encountered, about half of the time, the timeout is triggered on the peer node not handling the dialog preventing the call to be correctly terminated and also leaving entries in the dialog database which never get deleted.
https://kamailio.org/docs/modules/5.7.x/modules/dialog.html#dialog.p.enable…
Makes clear, that only the node which is handling the dialog in question, can make changes not related to the dialog profiles. So when a dialog times out, it is this node which has to trigger the timeout, not any other one.
When looking at the source code, it is clear, that the 'lifetime' is transmitted via DMQ dialog message to the peer nodes, which in turn arm a timer. So it is obvious, this time will trigger, sometimes before the instance handling the dialog itself triggers that timer.
With some assistance of @oej I found a way to alter the JSON payload to extend the lifetime on the peer nodes:
```
route[DMQ_CAPTURE]
{
if(is_method("KDMQ"))
{
if(has_body("application/json") && $fU == 'dialog')
{
if (jansson_get("lifetime", $rb, "$var(lifetime)"))
{
$var(new_lifetime) = $var(lifetime) + 60; # Add 60 seconds on DMQ peer to make sure it expires AFTER main node.
$var(newrb) = $rb;
jansson_set("integer", "lifetime", $var(new_lifetime), "$var(newrb)");
set_body("$var(newrb)","application/json");
msg_apply_changes();
}
}
dmq_handle_message();
exit;
}
}
```
Testing with this config fixed the issue of the timeout firing on a peer node instead of the node handling the dialog.
Issue is present in 5.5, 5.6 and after looking at the code, I assume also on 5.7
-Benoît
--
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/issues/3656
You are receiving this because you are subscribed to this thread.
Message ID: <kamailio/kamailio/issues/3656(a)github.com>