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
When receiving an INVITE over a specific LTE carrier, I'm seeing 'c=IN IP4
192.0.0.4' in SDP, which isn't technically a RFC1918 or RFC6598 IP address
and thus nat_uac_test(8) fails.
What elegant workaround can be done to catch such specific cases?
Thanks.
Hello,
I'm using RTPproxy for the first time in bridged mode and I can't get kamailio/rtpproxy to rewrite the c parameter to the correct public ip address of kamailio.
The setup is as following:
Carrier ------[fiber]------ Kamailio ---------[lan]--------- Freeswitch
Kamailio is listening on two interfaces:
1) Private: 172.0.0.1
2) Public: 192.168.0.1 (since we have a dedicated fiber with our carrier, this is its public address)
Freeswitch is listening on:
1) 172.0.0.2
Carrier is on:
1) 10.0.0.1
I've started an rtpproxy instance on the Kamailio box using:
rtpproxy -s udp:127.0.0.1:7721 -u rtpproxy rtpproxy -p /var/run/rtpproxy/rtpproxy.pid -l 192.168.0.1 172.0.0.1
I've played around with rtpproxy_manage() and the various flags (ie, ei), but I can't get kamailio to set the correct public IP when the 200 OK has to be sent back to the carrier.
It always sets it to its private address, instead of its public address.
I'm using Kamailio 4.2 with sippy/rtpproxy 2.0.
Could someone please point me into the right direction?
Thanks!
Grant
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.
Hi kamailios,
i have a creepy situation with v5.2.1 stable Kamilio. After a day or
so, Kamailio stop to process incoming SIP traffic via TCP. The
incoming TCP network packages get TCP-ACK from the OS (Debian 9,
4.18.0-15-generic-Linux) but Kamailio does not show any processing for
the SIP-Traffic incoming via TCP. No logs, nothing. While traffic via
UDP is working just totally fine.
When i look via command "netstat -ntp" is see, that the Recv-Q get
bigger and bigger. e.g.:
Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program
name tcp 4566 0 172.17.217.12:5060 xxx.xxx.xxx.xxx:57252 ESTABLISHED
31347/kamailio
After Kamailio restart, all is working fine again for a day. We have
maybe 10-20 devices online via TCP and low call volume (1-2 call per
minute). The only settings for tcp we have is "tcp_delayed_ack=no"
How to could we debug this situation? Again, no error, no warings in
the log. Just nothing.
Kristijan
Dear friends,
I am working on a program on Kamailio and rtpengine proxy. I am wondering whether can I set Kamailio and rtpengine daemon on different physical machines. For example, I set Kamailio on a machine with IP address:10.109.247.80, and launch rtpengine daemon on another machine with interface parameter as 10.109.247.90 and ng port 7723. I set parameter in Kamailio.cfg with modparam(“rtpengine”, “rtpengine_sock”, “udp:10.109.247.90:7723”).
Unfortunately I got debug message like this:
ERROR: rtpengine [rtpengine.c:1710]: send_rtpp_command(): can't send command to a RTP proxy
ERROR: rtpengine [rtpengine.c:1746]: send_rtpp_command(): proxy <udp:10.109.247.90:7723> does not respond, disable it
ERROR: rtpengine [rtpengine.c:1616]: rtpp_test(): proxy did not respond to ping
And, I also tried to set Kamailio and rtpengine daemon in a same machine,and use modparam(“rtpengine”, “rtpengine_sock”, “udp:localhost:7723”). And Kamailio can work functionally under this situation. rtpengine daemon can receive ping message from Kamailio and rtpengine daemon can work as suspected. So for the later case, is it supposed that Kamailio be in the same machine with same localhost address? Otherwise, what’s the reason for my ERROR?
------------------------------------
北京邮电大学网络技术研究院
网络与交换技术国家重点实验室
田军
+86 18810315790
mozillafire(a)bupt.edu.cn
------------------------------------
I need to send re-invite after pacemaker fails over on new rtpengine
server. Because new rtpengine dont participate in DTLS handshake and i hear
nothing, but silence. I think, may me its would be work. Do you have any
idea on this issue?
Hi Again,
Here is an issue with TCP connection being kept for more:
Yesterday, I have discovered that a User-Agent (<Avaya IP Phone 1120E
(SIP1120e.04.04.30.00)> tried to register a lot. It was sending REGISTER
over new established TCP socket *every 2 seconds*.
All the REGISTER was rejected with 401. (may be the device was
misconfigured? or not receiving any of my answer? I can't tell)
NOTE: You can see the expires header was very large: 86400, ie: 24 hours...
I was checking the TCP/TLS connections on my server and discovered more
than 1000 TCP established connection to that user/ip, and thus, I have
tried to understand what happened.
Checking the logs, I received 4855 REGISTER from this device from "Mar 25
03:47:09" to "Mar 25 07:56:13" which is a rate of approx one new TCP
connection every 2.5 seconds...
Today, I decided to check it again around 11am.
jack@sip:~$ sudo kamctl stats tcp
{
"jsonrpc": "2.0",
"result": [
"tcp:con_reset = 1857",
"tcp:con_timeout = 35927",
"tcp:connect_failed = 25",
"tcp:connect_success = 2",
"tcp:current_opened_connections = 2291",
"tcp:current_write_queue_size = 0",
"tcp:established = 80778",
"tcp:local_reject = 0",
"tcp:passive_open = 80776",
"tcp:send_timeout = 2",
"tcp:sendq_full = 0"
],
"id": 7305
}
There was still A LOT of established connections. And the connections have
been established more than 24 hours ago.
At 11H16:
$> lsof -n -l | grep kamailio | grep TCP | grep 41.234.242.69 | grep ESTA |
wc -l
1161
At 11H22:
$> lsof -n -l | grep kamailio | grep TCP | grep 41.234.242.69 | grep ESTA |
wc -l
1018
At 11H35:
$> lsof -n -l | grep kamailio | grep TCP | grep 41.234.242.69 | grep ESTA |
wc -l
655
At 13H
$> lsof -n -l | grep kamailio | grep TCP | grep 41.234.242.69 | grep ESTA |
wc -l
0
So the established connections are all gone now.
Between 11h16 and 11H35, I was seeing the server regularly sending [FIN,
ACK] over each TCP established connection, with retransmissions for all of
them. (no incoming trafic)
I do not have numbers/capture/stats, but I think that kamailio was already
closing some
connection yesterday. I don't know when kamailio started to try closing
those connections.
I'm now back with this status:
At 13pm:
jack@sip:~$ sudo kamctl stats tcp
{
"jsonrpc": "2.0",
"result": [
"tcp:con_reset = 1896",
"tcp:con_timeout = 38042",
"tcp:connect_failed = 26",
"tcp:connect_success = 2",
"tcp:current_opened_connections = 939",
"tcp:current_write_queue_size = 0",
"tcp:established = 81950",
"tcp:local_reject = 0",
"tcp:passive_open = 81948",
"tcp:send_timeout = 2",
"tcp:sendq_full = 0"
],
"id": 12734
}
With around 155 registration entries using TCP and TLS in my location
database.
As you can see, tcp:current_opened_connections = 939 is still pretty high
compared to
my currently registred users.
I have "modparam("registrar", "max_expires", 86400)", because I'm keeping
contact entries (even with TCP connection down) for push notifications.
I have "tcp_connection_lifetime=3600" configured.
Question 1
With "tcp_connection_lifetime=3600", I would expect kamailio to close the
established connection after 3600 seconds without traffic. It is pretty
obvious that no data has been exchanged over the 4855 established
connection during a day.
Despite the issue with the Avaya phones is solved automatically after a
day, I guess similar stuff or happening, at a different rate, for other
users as well. (because current_opened_connections is way higher than
registred TCP/TLS users)
Question 2
I can list TLS connection with "kamctl rpc tls.list"
Can I get a similar list for TCP? (lsof returns a lot of duplicates...)
Tks
Aymeric
--
Antisip - http://www.antisip.com
