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
Hello,
Using Kamailio 5.1.6 for load balancing & failover,
I noticed that from time to time, and very rarely, the dispatcher module
stops dispatching to the Asterisk servers.
I have to execute a "kamcmd dispatcher reload" for it to (re)start working.
This is my dispatcher.list :
1 sip:10.19.XXX.YYY:5060 0 1 duid=sipgw01;maxload=100
1 sip:10.19.XXX.YYY:5060 0 2 duid=sipgw02;maxload=100
1 sip:10.19.XXX.YYY:5060 0 3 duid=sipgw03;maxload=100
1 sip:10.19.XXX.YYY:5060 0 4 duid=sipgw04;maxload=100
This is my dispatch routes:
# Dispatch requests
route[DISPATCH] {
if(!ds_select_dst("1", "10","4"))
{
xlog("L_INFO","no destination selected from dispatcher
list!");
send_reply("404", "No destination");
exit;
}
xlog("L_INFO","going to <$ru> via <$du>\n");
t_on_failure("RTF_DISPATCH");
route(RELAY);
exit;
}
# Sample failure route
failure_route[RTF_DISPATCH] {
if (t_is_canceled()) {
exit;
}
xlog("L_INFO", "Media server $du failed to answer, selecting other
one!");
# next DST - only for 500 or local timeout
if ( t_check_status("500") || (t_branch_timeout() &&
!t_branch_replied()) )
{
#mark the destination Inactive and Probing
ds_mark_dst("ip");
if(ds_next_dst())
{
t_on_failure("RTF_DISPATCH");
route(RELAY);
exit;
}
}
}
I suspect that the ds_mark_dst("ip") command in RTF_DISPACTH is the cause.
Is there any think I can improve on this? Or any know bug with the
dispatcher in Kamailio 5.1.6 version?
Thanks in advance,
*Sérgio Charrua*
Hi,
sorry for quite stupid and newbie questions, but I am out of ideas.
1. On one of my Debian 10 servers I am unable to stop logging kamailio
messages to /var/log/syslog. It is funny, because I have 3 more servers
where it works but on this one, it doesnt and no matter what I try it
still keeps sending logs to syslog (and to the file configured).
My related configs:
/etc/kamailio/kamailio.cfg
log_stderror=no
log_facility=LOG_LOCAL7
/etc/rsyslog.conf
local6.* /var/log/kamailio/cdr.log
local7.* /var/log/kamailio/kamailio.log
/etc/rsyslog.d/kamailio.conf
if $programname contains 'kamailio' then /var/log/kamailio/kamailio.log
& stop
/etc/systemd/system/multi-user.target.wants/kamailio.service
SyslogIdentifier=kamailio
2. It is probably related to 1. I am unable to get the CDRs logged to
anything else but /var/log/syslog. I tried database (nothing) and
setting cdr_facility and again nothing. It just keeps sending everything
to /var/log/syslog.
Related configs:
modparam("acc", "cdr_enable", 1)
modparam("acc", "cdrs_table", "acc_cdrs")
modparam("acc", "cdr_facility", "LOG_LOCAL6")
Example output in syslog file:
Sep 30 09:21:41 sip2 /usr/sbin/kamailio[1151]: NOTICE: {2 21 INVITE
ZPZI7Hqytw} acc [acc.c:279]: acc_log_request(): ACC: call missed:
timestamp=1601450501;method=INVITE;from_tag=1GH5hGQxN;to_tag=QwcYFet;call_id=ZPZI7Hqytw;code=486;reason=Busy
here;src_user=XXXXXXXXX;
Is there something trivial I am missing?
Thank you. Regards, Jan
Hi,
I am a newbie to sipclient Linphone. I know this issue is not related with
kamailio.Yet If anybody have tried it before , kindly provide me with some
links or procedures to be followed for call registration and connectivity
with kamailio since in my case, request is going but response is not coming
back resulting in timeout issue.
This happens only in linphone.If i do the samething in PJSIP/zoiper, call
registration and call establishment happens perfectly fine.
Kindly help.
Thanks,
Pavithra
hi,
i have kamailio+rtpengine acting as a SBC (private/public net interfaces)
kamailio 5.4.x/rtpengine 9.x/centos 7
using TOPOH module
modparam("topoh", "mask_ip", "public_IP")
i'm rewriting IPs in INVITE like this
$var(ruri) = "sip:" + $(ru{re.subst,/private_IP/public_IP/g});
$ru = $(ru{re.subst,/private_IP/public_IP/g});
$tu = $(tu{re.subst,/private_IP/public_IP/g});
$fu = $(fu{re.subst,/remote_private_IP/public_IP/g});
the same for route[WITHINDIALOG] and INVITE
i have problem with session timers using re-INVITE method
in the first INVITE SDP is correct
c=IN IP4 public_IP
but
in the reinvite is
c=IN IP4 private_IP
and remote SBC drop with 422 because SDP is changed and SDP version is not.
any tips / best practice?
thanks
Marek
