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 all,
I'm using pipelimit with the "clean_unused" option to get rid of pipes that
are not used for quite some time. At the same time we are monitoring
pipelimit with a jsonrpc call similar to:
# curl --header 'Content-Type: application/json' --data-binary '{"id": 1,
"jsonrpc": "2.0", "method": "pl.list", "params": ["pipe_INVITE"]'
http://127.0.0.1:8000/RPC
Reply:
{
"jsonrpc": "2.0",
"error": {
"code": 400,
"message": "Unknown pipe id pipe_INVITE"
},
"id": 1
}
The above reply is valid because the pipe_INVITE was not loaded yet, but
the request makes kamailio to log the following log messages:
Jan 20 11:21:48 proxy1 kamailio[24474]: ERROR: pipelimit [pl_ht.c:519]:
rpc_pl_list(): no pipe: pipe_INVITE
Jan 20 11:21:48 proxy1 kamailio[24474]: ERROR: <core>
[core/parser/parse_fline.c:262]: parse_first_line(): parse_first_line: bad
message (offset: 20)
Jan 20 11:21:48 proxy1 kamailio[24474]: [466B blob data]
Since the monitoring system does periodic requests, those log lines get a
bit annoying and fill the log with ERROR messages that aren't really errors.
IMHO the first log line should be converted to DEBUG instead of ERROR, but
I have some doubts about the one from parse_fline.c:262. parse_first_line()
is used to process both SIP and HTTP. It makes sense to log ERROR if SIP
but not in the case of HTTP...
Regarding the "[466B blob data]" I really don't know from where it's coming
from.
I can submit a PR, but I would like to have first some feedback from you.
Thank you,
Nuno
--
*Confidentiality Notice: The information contained in this e-mail and any
attachments may be confidential. If you are not an intended recipient, you
are hereby notified that any dissemination, distribution or copying of this
e-mail is strictly prohibited. If you have received this e-mail in error,
please notify the sender and permanently delete the e-mail and any
attachments immediately. You should not retain, copy or use this e-mail or
any attachment for any purpose, nor disclose all or any part of the
contents to any other person. Thank you.*
Hello Team,
I need to configure apns sip push in kamailio, I have read it many sites but I don't get proper understanding I read it is done with the help of tsilo module kindly support in it.
Sent with [ProtonMail](https://protonmail.com) Secure Email.
‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On Thursday, February 27, 2020 11:10 AM, master1024 <master1024(a)protonmail.com> wrote:
> Hello,
>
> I need to configure apns push notification in kamailio kindly help. I have a file push.php It is capable to push notification on ios device know i want to implement in kamailio when the user is offline then push notification fire kindly help in this.
>
> Think Out of the Box
>
> Sent with [ProtonMail](https://protonmail.com) Secure Email.
Hello,
do people here have (implemented) special ways to properly start
rtpengine with kernel forwarding after system reboot?
>From rtpengine readme:
"""
A typical start-up sequence including in-kernel forwarding might look
like this:
# this only needs to be one once after system (re-) boot
modprobe xt_RTPENGINE
iptables -I INPUT -p udp -j RTPENGINE --id 0
ip6tables -I INPUT -p udp -j RTPENGINE --id 0
# ensure that the table we want to use doesn't exist - usually needed
after a daemon
# restart, otherwise will error
echo 'del 0' > /proc/rtpengine/control
# start daemon
/usr/sbin/rtpengine --table=0 --interface=10.64.73.31
--interface=2001:db8::4f3:3d \
--listen-ng=127.0.0.1:2223 --tos=184 --pidfile=/run/rtpengine.pid
--no-fallback
"""
I was relying on shell scripts executed on boot time, but now that
systemd is more common, I am looking to see what are
"standard"/"recommended" ways for running additional scripts besides the
start/stop daemon, which makes it also easier to build packages not
worrying about the type of OS and how it can run scripts at startup.
Systemd seems to have the "ExecStartPre" option, is it what people use
to ensure the rtpengine kernel module is loaded and iptables rule exists?
Any systemd-specific wayt to run a script only once after system boot? I
have seen workarounds on the net for creating like a rc.local service,
but they didn't look to be systemd-native, ...
Not strictly related, but if someone is aware or had some experiences
with, I am curious if "echo 'del 0' > /proc/rtpengine/control" is
really needed because on a system where I forgot to have it in the
scripts (well, was commented), I haven't noticed any issues after
rtpengine restarts.
Cheers,
Daniel
--
Daniel-Constantin Mierla -- www.asipto.comwww.twitter.com/miconda -- www.linkedin.com/in/miconda
Kamailio World Conference - April 27-29, 2020, in Berlin -- www.kamailioworld.com
K reported during about 90 sec period that it is out of shared memory:
Feb 28 09:47:28 rox1 /usr/bin/sip-proxy[19725]: ERROR: tm
[t_hooks.c:136]: insert_tmcb(): out of shm. mem
Feb 28 09:47:28 rox1 /usr/bin/sip-proxy[19725]: ERROR: acc
[acc_logic.c:394]: acc_onreq(): cannot register additional callbacks
Feb 28 09:47:28 rox1 /usr/bin/sip-proxy[19725]: ERROR: <core>
[core/sip_msg_clone.c:499]: sip_msg_shm_clone(): could not allocate
shared memory from shm pool
Feb 28 09:47:28 rox1 /usr/bin/sip-proxy[19725]: ERROR: tm
[t_lookup.c:1293]: new_t(): out of mem:
Feb 28 09:47:28 rox1 /usr/bin/sip-proxy[19725]: ERROR: tm
[t_lookup.c:1439]: t_newtran(): new_t failed
...
Feb 28 09:47:29 rox1 /usr/bin/sip-proxy[19725]: ERROR: <core>
[core/mem/q_malloc.c:297]: qm_find_free(): qm_find_free(0x7f1f2a506000,
1232); Free fragment not found!
Feb 28 09:47:29 rox1 /usr/bin/sip-proxy[19725]: ERROR: <core>
[core/mem/q_malloc.c:434]: qm_malloc(): qm_malloc(0x7f1f2a506000, 1232);
Free fragment not found!
Feb 28 09:47:29 rox1 /usr/bin/sip-proxy[19725]: ERROR: tm
[t_reply.c:1957]: relay_reply(): cannot alloc reply shmem
Feb 28 09:47:29 rox1 /usr/bin/sip-proxy[19725]: ERROR: <core>
[core/sip_msg_clone.c:499]: sip_msg_shm_clone(): could not allocate
shared memory from shm pool
Feb 28 09:47:29 rox1 /usr/bin/sip-proxy[19725]: ERROR: acc
[acc_logic.c:562]: acc_onreply(): failed to clone the request - acc aborted
...
Feb 28 09:48:51 rox1 /usr/bin/sip-proxy[19724]: ERROR: <core>
[core/mem/q_malloc.c:297]: qm_find_free(): qm_find_free(0x7f1f2a506000,
5728); Free fragment not found!
Feb 28 09:48:51 rox1 /usr/bin/sip-proxy[19724]: ERROR: <core>
[core/mem/q_malloc.c:434]: qm_malloc(): qm_malloc(0x7f1f2a506000, 5728);
Free fragment not found!
Feb 28 09:48:51 rox1 /usr/bin/sip-proxy[19724]: ERROR: tm
[t_lookup.c:1293]: new_t(): out of mem:
Feb 28 09:48:51 rox1 /usr/bin/sip-proxy[19724]: ERROR: tm
[t_lookup.c:1439]: t_newtran(): new_t failed
And after that period it started working normally again and
core.shmmem showed:
{
total: 134217728
free: 124173808
used: 9530960
real_used: 10043920
max_used: 134217728
fragments: 349
}
As can be seen, shm had been full, but normally only about 10% of it
is in use.
Syslog does not show any traffic spikes or other unusual activity before
the memory got full.
Any ideas what could cause such a high memory usage or could there be
a bug in shm management?
-- Juha
Hi,
During some tests with the module tmrec, we stumble upon an unexpected
behavior of the monthly recurrence with days of the week.
The last week does not match our expected date.
For example, the last Monday of March 2020 is day 30 (fifth Monday of the
month) however, neither the 5MO or -1MO configuration on the bday parameter
match with a timestamp configured to day 30. The same situation is verified
on months with only 4 weeks.
To easily explain the behavior we create this configuration:
$var(ts)="1584355625"; # Monday, March 16, 2020 10:47:05
if(tmrec_match("20200101T090000|PT8H|monthly||1|3MO||||","$(var(ts){s.int})"))
{
xlog("L_INFO","Epoch $var(ts) matches with 3MO\n");
}else{
xlog("L_INFO","Epoch $var(ts) doesn't match with 3MO\n");
}
$var(ts)="1584960425"; # Monday, March 23, 2020 10:47:05
if(tmrec_match("20200101T090000|PT8H|monthly||1|4MO||||","$(var(ts){s.int})"))
{
xlog("L_INFO","Epoch $var(ts) matches with 4MO\n");
}else{
xlog("L_INFO","Epoch $var(ts) doesn't match with 4MO\n");
}
$var(ts)="1585565225"; # Monday, March 30, 2020 10:47:05
if(tmrec_match("20200101T090000|PT8H|monthly||1|5MO||||","$(var(ts){s.int
})")){
xlog("L_INFO","Epoch $var(ts) matches with 5MO\n");
}else{
xlog("L_INFO","Epoch $var(ts) doesn't match with 5MO\n");
}
$var(ts)="1584960425"; # Monday, March 23, 2020 10:47:05
if(tmrec_match("20200101T090000|PT8H|monthly||1|-1MO||||","$(var(ts){s.int
})")){
xlog("L_INFO","Epoch $var(ts) matches with -1MO\n");
}else{
xlog("L_INFO","Epoch $var(ts) doesn't match with -1MO\n");
}
The results were:
Epoch 1584355625 matches with 3MO
Epoch 1584960425 matches with 4MO
Epoch 1585565225 doesn't match with 5MO
Epoch 1584960425 matches with -1MO
Are we configuring the tmrec_match wrongly?
--
Cumprimentos / Best regards,
*David Gonçalves*
Research and Development Technician
Phone: +351 256 370 980
Email: david.goncalves(a)itcenter.com.pt
Hello Everyone,
I have an IMS setup using Kamailo and is working as expected when the 4G
Core Network and IMS is running in a single VM. However, when running in
two different VMs registration is successful but calling fails. As per the
scripts in kamailio ims example folder for P-CSCF, uac module is used to
generate OPTIONS message to achieve a kind of NATPINGING to UEs.
The ping achieved in this way times out with 408 when IMS and Core Network
is run in different VMs.
I suspect that the increasing packets size could be the issue for UE not
responding to OPTIONS from P-CSCF (I have verified that OPTIONS message
from P-CSCF is reaching the eNB). In this aspect, I would like to switch
the transport protocol to TCP when MTU is greater than 1300 (please guide
me if my thinking of switching to TCP to tackle NAT issue is wrong).
I have explored the following options:
tcp_reuse_port=yes
udp_mtu=1300
udp_mtu_try_proto=TCP
But, when I use these options, any request message which hit 1300 MTU mark
are not sent out at all (in my case it is the NOTIFY request from SCSCF)
and Kamailio has a warning saying that binding to address failed as the
address is already in use.
Following is the small part of the log:
Feb 27 14:31:15 epc-ims /usr/local/sbin/kamailio[19712]: DEBUG:
ims_registrar_scscf [registrar_notify.c:2275]:
notification_event_process(): About to free notification
Feb 27 14:31:15 epc-ims /usr/local/sbin/kamailio[19730]: NOTICE: <script>:
PCSCF MO_reply:
Destination URI:
<null>
Request URI:
<null>
Feb 27 14:31:15 epc-ims /usr/local/sbin/kamailio[19730]: INFO: rr
[rr_mod.c:515]: pv_get_route_uri_f(): No route header present.
Feb 27 14:31:15 epc-ims /usr/local/sbin/kamailio[19730]: NOTICE: <script>:
Source IP and Port: (10.4.128.21:6060)
Route-URI:
Feb 27 14:31:15 epc-ims /usr/local/sbin/kamailio[19730]: NOTICE: <script>:
Received IP and Port: (10.4.128.21:5060)
Feb 27 14:31:15 epc-ims /usr/local/sbin/kamailio[19730]: NOTICE: <script>:
Contact header: <sip:scscf.ims.mnc001.mcc001.3gppnetwork.org:6060>
Feb 27 14:31:15 epc-ims /usr/local/sbin/kamailio[19730]: ERROR: <script>:
NOTIFY (tel:0198765432100 (172.24.15.30:6060) to tel:0198765432100,
4125089758_4268630712(a)192.168.101.2)
Feb 27 14:31:15 epc-ims /usr/local/sbin/kamailio[19730]: NOTICE: <script>:
Within DLG
Feb 27 14:31:15 epc-ims /usr/local/sbin/kamailio[19730]: NOTICE: <script>:
Within loose route
Feb 27 14:31:15 epc-ims /usr/local/sbin/kamailio[19730]: NOTICE: <script>:
PCSCF MO_indialog:
Destination URI:
sip:172.24.15.10:5060
Request URI: sip:
192.168.101.2:5060
Feb 27 14:31:15 epc-ims /usr/local/sbin/kamailio[19730]: NOTICE: <script>:
Source IP and Port: (172.24.15.30:6060)
Route-URI:
sip:mo@172.24.15.30;lr=on;ftag=4125089761
Feb 27 14:31:15 epc-ims /usr/local/sbin/kamailio[19730]: NOTICE: <script>:
Received IP and Port: (10.4.128.21:5060)
Feb 27 14:31:15 epc-ims /usr/local/sbin/kamailio[19730]: NOTICE: <script>:
Contact header: <sip:scscf.ims.mnc001.mcc001.3gppnetwork.org:6060>
Feb 27 14:31:15 epc-ims /usr/local/sbin/kamailio[19730]: WARNING: <core>
[core/tcp_main.c:1298]: tcp_do_connect(): binding to source address
10.4.128.21:5060 failed: Address already in use [98]
I could be assuming things here about huge packet sizes causing the issue,
if anyone has experienced similar issue in NATed scenario please let me
know some hints or pointer to solve this. Thanks in advance.
Best Regards,
Supreeth
Hi list,
there is an issue in latest git version of Siremis with showing sip method
content.
If I select it from mysql I see it all good:
select * from sip_trace where method = 'INVITE';
If I click it from web interface and select needed method I get only first
register from sip_trace table.
You can reproduce by /siremis/sipadmin/sip_trace_list
<http://sbc.pride.md/siremis/sipadmin/sip_trace_list> then click on the
method to see
details. I tested on opera and chrome. Same result, something wrong with
javascript, its not passing correctly parameter for selecting.
Please have a look let me know if I can help.
Thanks. Regards
Vitalie A. Bugaian