On Mon, May 07, 2018 at 04:44:14PM +0200, Daniel Tryba wrote:
> Sure. Attached. Problem appears to be that the topos query can't find
> callid-totag (from the response).
>
> I'll try the same scenario with the mysql backend to see if it behaves
> different.
Config works fine with mysql as topos backend. So the bug is restricted
to topos-redis.
Hi,
We’re still using kamailio 4.4 but we’ll be migrating to 5.0 soon.
Cool so it will be fixed when we migrate !
Thanks,
Andreas
From: sr-users [mailto:sr-users-bounces@lists.kamailio.org] On Behalf Of Federico Cabiddu
Sent: vendredi 12 mai 2017 11:56
To: Kamailio (SER) - Users Mailing List
Subject: Re: [SR-Users] t_drop_replies not working with t_suspend in failure route
Hi,
which version are you using?
A similar case had been reported some months ago and it should be fixed in 5.0.
Regards,
Federico
On Fri, May 12, 2017 at 11:44 AM, Huber Andreas <andreas.huber(a)nagra.com<mailto:andreas.huber@nagra.com>> wrote:
Hello,
We have a use case where we suspend a transaction in a failure_route to give UEs that might be woken by a push notification more time to REGISTER and join the INVITE.
We’d like to drop the previous branches in this case. I tried using t_drop_replies() but it has no effect.
The doc states that t_drop_replies() is only working if a new branch is added. And from my understanding t_suspend() adds a new branch.
But is it possible that t_drop_replies() cannot be used with t_suspend()? Or am I missing something?
Kind Regards,
Andreas
_______________________________________________
Kamailio (SER) - Users Mailing List
sr-users(a)lists.kamailio.org<mailto:sr-users@lists.kamailio.org>
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
Well, I saw similar questions in the list already but looks like nobody has
answer.
Please look at REFER below.
Kamilio get REFER from MS and sends it to FS node. Next, FS node try to
make 3th call for some reason.I expect that FS will not do 3th call and
just will connect Alice and Bob itself.
2020/05/14 12:32:00.637027 KAM_IP:5060 -> FS_IP:5060
REFER sip:Alice_number@FS_IP:5060;transport=udp SIP/2.0
FROM: Customer1<sip:MS_TRUNK_NUMBER@sip.pstnhub.microsoft.com:5061
;user=phone>;tag=a860c50a3fb54d08b4e5740fa2dfb3d6
TO: <sip:Alice_number@FQDN_OF_TRUNK:5061>;user=phone;tag=e8ct9S6ty13va
CSEQ: 4 REFER
CALL-ID: 2c71b2a6669b5343a231e1244b19c945
MAX-FORWARDS: 50
Via: SIP/2.0/UDP
FQDN_OF_TRUNK:5060;branch=z9hG4bK10ae.2c42897feca117121a23bf0c8d54cd19.0;i=c
VIA: SIP/2.0/TLS 52.114.75.24:5061;branch=z9hG4bK7e3e8998
CONTACT: <sip:api-du-a-euwe.pstnhub.microsoft.com:443
;x-i=6b68e7aa-f5e2-44ec-9edf-0bacbabfce07;x-c=2c71b2a6669b5343a231e1244b19c945/d/8/b68f86794a8e44d19543f8edbee6b2fc
CONTENT-LENGTH: 0
REFER-TO: <sip:Bob_number@sip.pstnhub.microsoft.com:5061
;user=phone;transport=tls>
REFERRED-BY: <sip:sip.pstnhub.microsoft.com:5061
;x-m=8:orgid:21bc47d3-c050-4292-8234-46f7005b97aa;x-t=fb788ef8-3c4c-455a-8d62-f3c20832c0d3;x-ti=6b68e7aa-f5e2-44ec-9edf-
acbabfce07;x-tt=aHR0cHM6Ly9hcGktZHUtYS1ldXdlLnBzdG5odWIubWljcm9zb2Z0LmNvbS92MS9uZ2MvY2FsbG5vdGlmaWNhdGlvbj9kY2k9YzIxMjE3MzEyNTQ2NDk1ZjlhYTcwODliYTkwNGIxZGQ%3D>
USER-AGENT: Microsoft.PSTNHub.SIPProxy v.2020.5.6.2 i.EUWE.4
ALLOW: INVITE,ACK,OPTIONS,CANCEL,BYE,NOTIFY
P-ASSERTED-IDENTITY: <tel:MS_TRUNK_NUMBER>,<
sip:customer1@m365x587912.onmicrosoft.com>
PRIVACY: id
X-AUTH-IP: 52.114.75.24
X-AUTH-PORT: 3136
Any advice?
Dear all
We are trying to use the evapi module to send some data to an external
application but I'm having problems getting the clients connected.
I have the kamailio (version 5.3) running with a tcp socket 127.0.0.1:8228,
and the evapi params are just
modparam("evapi", "workers", 4)
modparam("evapi", "netstring_format", 0)
modparam("evapi", "bind_addr", "127.0.0.1:8448")
modparam("evapi", "max_clients", 32)
I tried a different number of workers and netstring_format 1 too.
When I start the kamailio i added some debug to the code, and seems when
doing the mod init of the evapi dispatcher
38(4779) DEBUG: <core> [core/sr_module.c:779]: init_mod_child(): idx 38
rank -2: evapi [EvAPI Dispatcher]
it reaches to
while(1) {
ev_loop (loop, 0);
}
at evapi_run_dispatcher function.
I guess if I connected to the tcp socket and sent some event, I would see
the client accepted and the event route evapi:connection-new would be
triggered. But i'm not able to do that.
I tried to use the prime option, a tcp input client connection from
logstash, so i could relay the data to the logstash using the evapi relay,
but i only see the tcp socket being created but no client accepted.
I also tried to connect with an erlang gen_tcp client, but it's the same
i only see
47(4798) DEBUG: <core> [core/ip_addr.c:229]: print_ip(): tcpconn_new: new
tcp connection: 127.0.0.1
47(4798) DEBUG: <core> [core/tcp_main.c:1174]: tcpconn_new(): on port
54537, type 2, socket 105
47(4798) DEBUG: <core> [core/tcp_main.c:1497]: tcpconn_add(): hashes:
1117:1187:1505, 1
47(4798) DEBUG: <core> [core/io_wait.h:375]: io_watch_add(): DBG:
io_watch_add(0xad0880, 105, 2, 0x7fc211712d58), fd_no=53
and if i try to send any data
47(4798) DEBUG: <core> [core/io_wait.h:600]: io_watch_del(): DBG:
io_watch_del (0xad0880, 105, -1, 0x0) fd_no=54 called
47(4798) DEBUG: <core> [core/tcp_main.c:4456]: handle_tcpconn_ev(): sending
to child, events 1
47(4798) DEBUG: <core> [core/tcp_main.c:4129]: send2child(): selected tcp
worker idx:0 proc:43 pid:4791 for activity on [tcp:127.0.0.1:8448],
0x7fc211712d58
43(4791) DEBUG: <core> [core/tcp_read.c:1749]: handle_io(): received n=8
con=0x7fc211712d58, fd=39
43(4791) DEBUG: <core> [core/io_wait.h:375]: io_watch_add(): DBG:
io_watch_add(0xb3c720, 39, 2, 0x7fc211712d58), fd_no=1
43(4791) DEBUG: <core> [core/io_wait.h:600]: io_watch_del(): DBG:
io_watch_del (0xb3c720, 39, -1, 0x10) fd_no=2 called
43(4791) DEBUG: <core> [core/tcp_read.c:1671]: release_tcpconn(): releasing
con 0x7fc211712d58, state 1, fd=39, id=1 ([127.0.0.1]:54537 ->
[127.0.0.1]:8448)
43(4791) DEBUG: <core> [core/tcp_read.c:1672]: release_tcpconn():
extra_data (nil)
47(4798) DEBUG: <core> [core/tcp_main.c:3559]: handle_tcp_child(): reader
response= 7fc211712d58, 1 from 0
47(4798) DEBUG: <core> [core/io_wait.h:375]: io_watch_add(): DBG:
io_watch_add(0xad0880, 105, 2, 0x7fc211712d58), fd_no=53
47(4798) DEBUG: <core> [core/tcp_main.c:3686]: handle_tcp_child():
CONN_RELEASE 0x7fc211712d58 refcnt= 1
and when i try to send any data
38(10867) DEBUG: evapi [evapi_dispatch.c:610]: evapi_recv_notify():
received [0x7f17d23fc628] [{"test" : "1.1.1.1", "uuid" : "1-31629(a)3.3.3.3"
, "pdd" : "4"}] (75)
38(10867) DEBUG: evapi [evapi_dispatch.c:316]: evapi_dispatch_notify(): the
message was sent to 0 clients
I don't know what i'm missing, or if i'm understanding the use of the
module correctly
could you please take a look?
thanks a lot
David
--
[image: Logo]
David Escartín Almudévar
VoIP/Switch Engineer
descartin(a)sonoc.io
*SONOC*
C/ Josefa Amar y Borbón, 10, 4ª · 50001 Zaragoza, España
Tlf: +34 917019888 · www.sonoc.io
Hi everyone,
I've got a specific case: when the inv_fr times out, I need to add a Reason
header to the CANCEL generated by kamailio. I've tried to see if I could do
it in the onsend_route, but that one is not triggered for the generated
CANCEL. I also checked event_route[tm:local-request], but that one isn't
triggered either for the generated CANCEL.
Is there any way to do it? Or maybe to have any pointer about where to look
in the code so I may try to trigger event_route[tm:local-request] for these
generated CANCELs?
Regards,
Alfonso
Hi,
I have several Kamailio proxies - loadbalancer which is used as TLS offload
and Authorization server and behind registrar servers.
In this case I can't make tsilo work on the registrar server.
I'm always getting: "tm [t_append_branches.c:172]: t_append_branches():
failure to add branches (-1)"
If I use just one Kamailio which is used as Authorization and Registrar
server then tsilo works as expected.
Looks like kamailio where I run ts_append tries to connect to UAC directly
and not through Loadbalancer.
Any ideas? How can I troubleshoot this?
Thank you!
Jurijs
Running 5.5.0-dev3
modparam("htable", "htable", "ipban=>size=8;autoexpire=300;dmqreplicate=1;")
modparam("htable", "enable_dmq", 1)
modparam("htable", "dmq_init_sync", 1)
modparam("htable", "timer_procs", 4)
modparam("htable", "timer_interval", 5)
modparam("htable", "db_expires", 1)
modparam("htable", "htable", "account=>size=4;dmqreplicate=1;")
modparam("htable", "htable", "server=>size=4;autoexpire=15;")
I'm attempting to retrieve an auth token in the init process and also
refresh the token upon expiration in the htable:expired event.
I'm seeing some behavior where every other execution of htable:expired the
variable $sht(server=>auth::token) is set per kamcmd htable.dump server,
however xinfo() reports that the token was retrieved in the variable $sht
(server=>auth::token).
Please see remaining event route config below:
event_route[htable:mod-init] {
# generate auth token into
http_client_query("https://www.cryy.com/api/auth/token", '{"email": "
brandon(a)cryy.com", "password":"XXXX"}', "$var(result)");
sht_lock("server=>auth::token");
$sht(server=>auth::token) = $var(result);
sht_unlock("server=>auth::token");
xinfo("AUTH_TOKEN_RECEIVED, $sht(server=>auth::token)");
}
event_route[htable:expired:server] {
# process expired htable, renew auth token
xinfo("AUTH_TOKEN_EXPIRED, lets retrieve a new one");
http_client_query("https://www.cryy.com/api/auth/token", '{"email": "
brandon(a)cryy.com", "password":"XXXX"}', "$var(result)");
sht_lock("server=>auth::token");
$sht(server=>auth::time) = $TS;
$sht(server=>auth::token) = $var(result);
sht_unlock("server=>auth::token");
xinfo("AUTH_TOKEN_RECEIVED, $sht(server=>auth::token)");
xinfo("AUTH_TOKEN_TIME, $sht(server=>auth::time)");
}
I've tried both with locking and unlocking. Also one last thing worth
mentioning is that on the alternation where kamcmd htable.dump server shows
no auth token, $sht(server=>auth::time) is available, when the auth token
is visible in kamcmd htable.dump server there is no sht(server=>auth::time)
returned.
Also just to be explicitly clear -- xinfo() always returns AUTH_TOKEN_RECEIVED
correctly in both event routes.
Perhaps I'm over looking something -- thank you for the help in advance.
- Brandon
Hello,
I am planning to release Kamailio v5.3.7 sometime next week, likely on
Monday or Tuesday, this being the usual prior notice for heads up to
identify issues not reported yet on bug tracker as well as the commits
you are aware of that were not backported yet.
Cheers,
Daniel
--
Daniel-Constantin Mierla -- www.asipto.comwww.twitter.com/miconda -- www.linkedin.com/in/miconda
Hey all,
I’m a little stuck on an implementation of a set of dispatchers via TCP. There are some oddities about the behavior of the TCP source port of the Kamailio tcp worker/s, and maybe this is expected, but it doesn’t seem valid. For instance, I have a dispatcher:
"RECORDS": [{
"SET": {
"ID": 1,
"TARGETS": [{
"DEST": {
"URI": “sip:2.2.2.2:5060;transport=tcp",
"FLAGS": "AP",
"PRIORITY": 5
}
}]
}
}]
But when Kamailio sends an OPTIONS keep alive, the source port for the worker is 33940, and not 5060 (which is the TCP listen port), as received by Freeswitch:
recv 447 bytes from tcp/[1.1.1.1]:33940 at 18:58:24.958720:
------------------------------------------------------------------------
OPTIONS sip:2.2.2.2:5060;transport=tcp SIP/2.0
Via: SIP/2.0/TCP 1.1.1.1;branch=z9hG4bK1525.80a9e442000000000000000000000000.0
To: <sip:2.2.2.2:5060;transport=tcp>
From: <sip:inbound-kamailio-01>;tag=3c52ba62ee4c4621b9660728159919d3-cda8066f
CSeq: 10 OPTIONS
Call-ID: 3aa18693487268dc-2790(a)1.1.1.1
Max-Forwards: 70
Content-Length: 0
User-Agent: kamailio (5.4.2 (x86_64/linux))
------------------------------------------------------------------------
Also, I get weird debug messages when this tcp worker is spun up (specifically about Resource temporarily unavailable):
11(2790) DEBUG: dispatcher [dispatch.c:3340]: ds_ping_result_helper(): probe all, mode DS_PROBE_ALL
11(2790) DEBUG: dispatcher [dispatch.c:3383]: ds_ping_set(): probing set #1, URI sip:2.2.2.2:5060;transport=tcp
11(2790) DEBUG: dispatcher [dispatch.c:3414]: ds_ping_set(): Default ping_from: sip:inbound-kamailio-01
11(2790) DEBUG: dispatcher [dispatch.c:3424]: ds_ping_set(): Default outbound proxy:
11(2790) DEBUG: tm [uac.c:450]: t_uac_prepare(): next_hop=<sip:2.2.2.2:5060;transport=tcp>
11(2790) DEBUG: tm [uac.c:158]: dlg2hash(): hashid 21073
11(2790) DEBUG: <core> [core/tcp_main.c:1993]: tcp_send(): no open tcp connection found, opening new one
11(2790) DEBUG: <core> [core/ip_addr.c:229]: print_ip(): tcpconn_new: new tcp connection: 2.2.2.2
11(2790) DEBUG: <core> [core/tcp_main.c:1175]: tcpconn_new(): on port 5060, type 2, socket -1
11(2790) DEBUG: <core> [core/tcp_main.c:1494]: tcpconn_add(): hashes: 2712:0:0, 1
11(2790) DEBUG: <core> [core/tcp_main.c:2886]: tcpconn_1st_send(): pending write on new connection 0x7f24e64c1e18 sock 8 (-1/447 bytes written) (err: 11 - Resource temporarily unavailable)
11(2790) DEBUG: tm [uac.c:678]: send_prepared_request_impl(): uac: 0x7f24e65285a8 branch: 0 to 2.2.2.2:5060
11(2790) DEBUG: <core> [core/onsend.c:50]: run_onsend(): required parameters are not available - ignoring
27(2806) DEBUG: <core> [core/tcp_main.c:3792]: handle_ser_child(): read response= 7f24e64c1e18, 5, fd 46 from 11 (2790)
27(2806) DEBUG: <core> [core/io_wait.h:375]: io_watch_add(): DBG: io_watch_add(0x56490f0f8060, 46, 2, 0x7f24e64c1e18), fd_no=37
27(2806) DEBUG: <core> [core/io_wait.h:782]: io_watch_chg(): DBG: io_watch_chg (0x56490f0f8060, 46, 0x1, 0xffffffff) fd_no=38 called
27(2806) DEBUG: <core> [core/io_wait.h:600]: io_watch_del(): DBG: io_watch_del (0x56490f0f8060, 46, -1, 0x0) fd_no=38 called
27(2806) DEBUG: <core> [core/tcp_main.c:4457]: handle_tcpconn_ev(): sending to child, events 1
27(2806) DEBUG: <core> [core/tcp_main.c:4127]: send2child(): selected tcp worker idx:0 proc:19 pid:2798 for activity on [tcp:1.1.1.1:5060], 0x7f24e64c1e18
19(2798) DEBUG: <core> [core/tcp_read.c:1749]: handle_io(): received n=8 con=0x7f24e64c1e18, fd=8
19(2798) DEBUG: <core> [core/tcp_read.c:1548]: tcp_read_req(): content-length=0
19(2798) DEBUG: <core> [core/parser/msg_parser.c:620]: parse_msg(): SIP Reply (status):
19(2798) DEBUG: <core> [core/parser/msg_parser.c:622]: parse_msg(): version: <SIP/2.0>
19(2798) DEBUG: <core> [core/parser/msg_parser.c:624]: parse_msg(): status: <200>
19(2798) DEBUG: <core> [core/parser/msg_parser.c:626]: parse_msg(): reason: <OK>
19(2798) DEBUG: <core> [core/parser/parse_via.c:1303]: parse_via_param(): Found param type 232, <branch> = <z9hG4bK1525.80a9e442000000000000000000000000.0>; state=6
19(2798) DEBUG: <core> [core/parser/parse_via.c:1303]: parse_via_param(): Found param type 235, <rport> = <33940>; state=16
19(2798) DEBUG: <core> [core/parser/parse_via.c:2639]: parse_via(): end of header reached, state=5
19(2798) DEBUG: <core> [core/parser/msg_parser.c:498]: parse_headers(): Via found, flags=2
19(2798) DEBUG: <core> [core/parser/msg_parser.c:500]: parse_headers(): this is the first via
19(2798) DEBUG: <core> [core/parser/parse_addr_spec.c:185]: parse_to_param(): add param: tag=1mB9HryQ8ZBFc
19(2798) DEBUG: <core> [core/parser/parse_addr_spec.c:864]: parse_addr_spec(): end of header reached, state=29
19(2798) DEBUG: <core> [core/parser/msg_parser.c:171]: get_hdr_field(): <To> [59]; uri=[sip:2.2.2.2:5060;transport=tcp]
19(2798) DEBUG: <core> [core/parser/msg_parser.c:174]: get_hdr_field(): to body (39)[<sip:2.2.2.2:5060;transport=tcp>], to tag (13)[1mB9HryQ8ZBFc]
19(2798) DEBUG: <core> [core/parser/msg_parser.c:152]: get_hdr_field(): cseq <CSeq>: <10> <OPTIONS>
19(2798) DEBUG: <core> [core/receive.c:319]: receive_msg(): --- received sip message - reply - call-id: [3aa18693487268dc-2790(a)1.1.1.1] - cseq: [10 OPTIONS]
19(2798) DEBUG: <core> [core/parser/msg_parser.c:185]: get_hdr_field(): content_length=0
19(2798) DEBUG: <core> [core/parser/msg_parser.c:89]: get_hdr_field(): found end of header
Are these SIP messages expected to come from other ports than the listen port (5060 in this case)? Also, if the worker source port is not 5060, shouldn’t the SIP message get updated with the correct port?
In the case of OPTIONS, Freeswitch is replying correctly to the source port: 33940.
However, in the case of an in dialog BYE, Freeswitch is NOT replying to the source port of the Kamailio messages, but only to port 5060. Here is an example (relayed from web sockets to freeswitch over TCP) INVITE (as received from Freeswitch):
recv 1481 bytes from tcp/[1.1.1.1]:33940 at 16:56:47.920698:
------------------------------------------------------------------------
INVITE sip:991012@sip.domain <sip:991012@sip.domain>.com SIP/2.0
Record-Route: <sip:1.1.1.1;transport=tcp;r2=on;lr;nat=yes>
Record-Route: <sip:1.1.1.1:5061;transport=tls;r2=on;lr;nat=yes>
Via: SIP/2.0/TCP 1.1.1.1;branch=z9hG4bKd408.3f53e940ccb20c1033df4b3a8ebd8a34.0;i=1
Via: SIP/2.0/TLS 172.22.199.110:55304;received=5.5.5.5;rport=39518;branch=z9hG4bKPj5Css6JomCt9Cli2cCINbXi4FbPM5wewG;alias
Max-Forwards: 69
From: "Noah Mehl" <sip:5135555555@inbound-jail>;tag=s3i3y2tiOCgnUId5TD4Vp0UChf9GyEy9
To: <sip:991012@inbound-jail>
Contact: <sip:74895612@172.22.199.110:54887;transport=tls;alias=5.5.5.5~39518~3>
Call-ID: 5aoRBMBHahxqSLzrIpFnlfRz.UcGsmfq
CSeq: 27271 INVITE
Allow: SUBSCRIBE, NOTIFY, INVITE, ACK, BYE, CANCEL, UPDATE, MESSAGE, REFER
Supported: replaces, norefersub, gruu
User-Agent: Blink Pro 4.6.0 (MacOSX)
Content-Type: application/sdp
Content-Length: 528
v=0
o=- 3812979407 3812979407 IN IP4 5.5.5.5
s=Blink Pro 4.6.0 (MacOSX)
t=0 0
m=audio 50016 RTP/SAVP 113 0 101
c=IN IP4 5.5.5.5
a=rtcp:50017
a=rtpmap:113 opus/48000/2
a=fmtp:113 useinbandfec=1
a=rtpmap:0 PCMU/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=crypto:1 AES_CM_128_HMAC_SHA1_80 inline:UhHq6hth9HqALmiJ3AEeoGkixObBzkLURG60wJKT
a=crypto:2 AES_CM_128_HMAC_SHA1_32 inline:VKYaSCVwgvXCPaRvudTrgLORhWmOA7wyDJVeGjcu
a=sendrecv
a=oldmediaip:172.22.199.110
a=oldmediaip:172.22.199.110
------------------------------------------------------------------------
This doesn’t seem valid, as the top Via doesn’t have a port specified?
For reference, just rebuilt form the 5.4 branch today:
commit 62dff5b8b157236cae7defe64291a6e4a8ae27b5 (upstream/5.4)
Author: Kamailio Dev <kamailio.dev(a)kamailio.org>
Date: Wed Oct 28 20:16:28 2020 +0100
modules: readme files regenerated - modules ... [skip ci]
Thanks!
~Noah
