Hi,
I have the following weird problem. A Kamailio (5.4.x) with some asynchronous permission logic suspends outgoing INVITEs and resumes them after the answer of the permission system. Everything works as expected when the call is answered. However, when the called party rejects the call (with a 486 for example), the call doesn't get torn down immediately (it is rejected with a 408 eventually) because Kamailio logs the following:
Nov 23 14:51:02 host /usr/sbin/kamailio[1569]: DEBUG: app_python [apy_kemi.c:106]: sr_kemi_config_engine_python(): execution of route type 4 with name [ksr_onreply_manage] returned 1
Nov 23 14:51:02 host /usr/sbin/kamailio[1569]: DEBUG: tm [t_reply.c:1363]: t_should_relay_response(): ->>>>>>>>> T_code=183, new_code=486
Nov 23 14:51:02 host /usr/sbin/kamailio[1569]: DEBUG: tm [t_reply.c:1448]: t_should_relay_response(): store - other branches still active
Nov 23 14:51:02 host /usr/sbin/kamailio[1569]: DEBUG: tm [t_reply.c:1926]: relay_reply(): reply status=3 branch=2, save=1, relay=-1 icode=0 msg status=486
I don't do any forking, the call is just forwarded.
I put the following line immediately after t_suspend() and in the beginning of the route specified in t_continue():
KSR.info("We're at branch index %d" % KSR.pv.get("$T(branch_index)"))
This produces the following output:
Nov 23 16:30:13 host /usr/sbin/kamailio[2745]: INFO: <core> [core/kemi.c:104]: sr_kemi_core_info(): We're at branch index 0
Nov 23 16:30:13 host /usr/sbin/kamailio[2725]: INFO: <core> [core/kemi.c:104]: sr_kemi_core_info(): We're at branch index 2
So apparently, the suspend and continue introduce new branches. (Other option: I'm doing something completely different creating those branches, but I don't have any append_branch() or similar in my code.)
I assume, I just missed a configuration parameter. Can I get Kamailio somehow to behave as if there was just one branch and forward the negative reply?
Thanks,
Sebastian
Hello!
In some cases, I need to forcibly unregister a remote SIP account through
uac module, and then immediately register.
To unregister I can use the command:
*kamcmd uac.reg_unregister l_uuid <account>*
But it's not clear how to immediately register back. For example, these
commands do not give the desired effect:
*kamcmd uac.reg_enable l_uuid <account>*
*kamcmd uac.reg_reload*
[root@kamailio]# kamailio -V
version: kamailio 5.5.2 (x86_64/linux) 55e232
--
BR,
Denys Pozniak
Hello,
Kamailio SIP Server v5.5.3 stable release is out.
This is a maintenance release of the latest stable branch, 5.5, that
includes fixes since the release of v5.5.2. There is no change to
database schema or configuration language structure that you have to do
on previous installations of v5.5.x. Deployments running previous v5.5.x
versions are strongly recommended to be upgraded to v5.5.3.
For more details about version 5.5.3 (including links and guidelines to
download the tarball or from GIT repository), visit:
* https://www.kamailio.org/w/2021/11/kamailio-v5-5-3-released/
RPM, Debian/Ubuntu packages will be available soon as well.
Many thanks to all contributing and using Kamailio!
Cheers,
Daniel
--
Daniel-Constantin Mierla -- www.asipto.comwww.twitter.com/miconda -- www.linkedin.com/in/miconda
Hello,
I am considering to release Kamailio v5.5.3 sometime next week, likely
on Wednesday or Thursday (Nov 24/25, 2021). This is the usual heads up
notification to see if anyone is aware of issues not yet reported to bug
tracker and if yes, do it as soon as possible to give them a chance to
be fixed.
Cheers,
Daniel
--
Daniel-Constantin Mierla -- www.asipto.comwww.twitter.com/miconda -- www.linkedin.com/in/miconda
Hello,
I'm using Kamailio 5.5.2 with UDP sockets, configured with 32 children processes.
During load tests, some packets seem to be dropped. I'm trying to figure out why, and how to solve (or mitigate) the issue.
>From what I understand :
< the SIP messages send on UDP/SCTP are received directly from the buffer in kernel one by one, each being processed once read. >
(this is a message from Daniel-Constantin Mierla, posted on the mailing list back in 2014 - I assume this is still accurate)
So Kamailio does not handle its own buffers for incoming messages, but simply pulls one message from the kernel queue whenever a process is available for processing.
(Correct me if this is not true)
Hereafter some system parameters that seem interesting to me.
In particular, < net.core.rmem.default > seem very low (0,33 MB). But < net.core.rmem.max > is much higher (16 MB).
Looking at the code in function probe_max_receive_buffer (src\core\udp_server.c), it seems Kamailio is trying to increase the buffer size from the default.
However this does not seem to be working, seeing the following logs upon startup :
0(7602) INFO: <core> [core/udp_server.c:154]: probe_max_receive_buffer(): SO_RCVBUF is initially 349520
0(7602) INFO: <core> [core/udp_server.c:206]: probe_max_receive_buffer(): SO_RCVBUF is finally 349520
0(7602) INFO: <core> [core/udp_server.c:154]: probe_max_receive_buffer(): SO_RCVBUF is initially 349520
0(7602) INFO: <core> [core/udp_server.c:206]: probe_max_receive_buffer(): SO_RCVBUF is finally 349520
0(7602) INFO: <core> [core/udp_server.c:154]: probe_max_receive_buffer(): SO_RCVBUF is initially 349520
0(7602) INFO: <core> [core/udp_server.c:206]: probe_max_receive_buffer(): SO_RCVBUF is finally 349520
Is there something I don't understand ? could it be a bug ?
One quick fix I can think of would be to increase < net.core.rmem.default >. Considering that I don't have many sockets (3 used by Kamailio), I think I could set this to 16 MB (my VMs have 8 GB of allocated RAM).
What do you think ?
Thanks in advance for your help.
My system parameters :
net.core.rmem_default = 349520
net.core.rmem_max = 16777216
# => 0,33 MB / 16 MB respectively
* net.core.rmem_default, net.core.rmem_max - default and max socket receive buffer size in bytes. Each socket gets rmem_default reveive buffer size by default, and can request up to rmem_max with setsockopt<http://man7.org/linux/man-pages/man2/setsockopt.2.html> option SO_RCVBUF.
net.ipv4.udp_mem = 188856 251809 377712
* net.ipv4.udp_mem = "min pressure max" - these are numbers of PAGES (4KB) available for all UDP sockets in the system. min, pressure and max controls how memory is managed, but main point is that max is maximum size in PAGES for all UDP bufers in system. These values are set on boot time (if sysctls are not explicitly set) according to available RAM size.
# 377712 x 4 KB => 1475 MB
net.ipv4.udp_rmem_min = 4096
* net.ipv4.udp_rmem_min, net.ipv4.udp_wmem - minimal size for receive/send buffers (in bytes), guaranteed for each socket, even if if buffer size of all UDP sockets exceeds pressure parameter in net.ipv4.udp_mem.
Regards,
Nicolas.
This message contains information that may be privileged or confidential and is the property of the Capgemini Group. It is intended only for the person to whom it is addressed. If you are not the intended recipient, you are not authorized to read, print, retain, copy, disseminate, distribute, or use this message or any part thereof. If you receive this message in error, please notify the sender immediately and delete all copies of this message.
Hello!
On REGISTER I have a Contact header like
Contact: <sip:90002@192.168.0.26:48579;transport=TLS>;some_id=90002-21080
But on calling fix_nated_register() -> save(), param some_id is lost from
info, so, on INVITE to this account, some_id not appears in RURI.
Is this a bug or a feature and I do need to find some workaround?
--
Best regards,
Igor
Hello,
I am attempting to perform some asynchronous lookup upon receiving an INVITE and then reply with a 3xx response with a modified From header. My workflow now is to create a transaction when receiving the INVITE, suspend the transaction, perform the asynchronous lookup, continue the transaction upon response, and then modify the From header and reply. The ONLY problem I am having is modifying the From header! How can I modify the From header in this scenario?
function ksr_request_route()
if KSR.is_INVITE() then
if KSR.tm.t_newtran() then
cache_transaction_info()
KSR.tmx.t_suspend()
--perform async loookup
end
end
return 1
end
--This function called on response from async lookup. Equivalent of ONREPLY_ROUTE
function ksr_reply_route()
--Finds the transaction_index and transaction_label from a cache
KSR.tmx.t_continue(transaction_index, transaction_label, "redirect_transaction");
KSR.x.drop()
return 1
end
function redirect_transaction()
KSR.pv.sets("$fU", "Jenny") --Doesn't actually modify the from username for 302 response!
KSR.tm.t_reply(302, "Redirecting")
return 1
end
Thank you much!
-Michael
Hi
send_reply("403", "+411234567 transit disallowed");
Causes the reply to be truncated after the e164 number.
send_reply("403", "Forbidden +411234567 transit disallowed");
Causes the reply to be truncated after 'Forbidden'.
Is there a special meaning to the + character?
--
Mit freundlichen Grüssen
-Benoît Panizzon- @ HomeOffice und normal erreichbar
--
I m p r o W a r e A G - Leiter Commerce Kunden
______________________________________________________
Zurlindenstrasse 29 Tel +41 61 826 93 00
CH-4133 Pratteln Fax +41 61 826 93 01
Schweiz Web http://www.imp.ch
______________________________________________________