<div dir="ltr">Hi Andrew<div><br></div><div>A very simple place to start -- have you tried upping the memory allocations in /etc/default/kamailio to see if it fixes the issues? We had some issues with shared memory that went away when we changed around these settings.</div>
<div><br></div><div>All the best.</div><div><br></div><div>Will Ferrer</div><div><br></div><div><br></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Fri, Nov 29, 2013 at 11:30 AM,  <span dir="ltr"><<a href="mailto:elactrum@jamailca.com" target="_blank">elactrum@jamailca.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi,<br>
<br>
I have a Kamailio 3.3.3 server that currently reports the following errors upon execution of t_relay() for certain initial INVITEs.<br>
<br>
daemon.err /usr/sbin/kamailio[26916]: ERROR: <core> [sip_msg_clone.c:505]: ERROR: sip_msg_cloner: cannot allocate memory<br>
daemon.err /usr/sbin/kamailio[26916]: ERROR: tm [t_lookup.c:1338]: ERROR: new_t: out of mem:<br>
daemon.err /usr/sbin/kamailio[26917]: ERROR: tm [t_lookup.c:1478]: ERROR: t_newtran: new_t failed<br>
<br>
I understand this error to be related to shared memory, based on [1]. However, sercmd reports normal shared memory utilization:<br>
<br>
# sercmd core.shmmem<br>
{<br>
        total: 67108864<br>
        free: 43189728<br>
        used: 20505784<br>
        real_used: 23919136<br>
        max_used: 65948568<br>
        fragments: 36887<br>
}<br>
<br>
These figures are quite similar to another server with the same configuration and Kamailio version, which is not reporting out-of-memory errors.<br>
<br>
# sercmd core.shmmem<br>
{<br>
        total: 67108864<br>
        free: 40219536<br>
        used: 23241952<br>
        real_used: 26889328<br>
        max_used: 66306288<br>
        fragments: 37832<br>
}<br>
<br>
<br>
I recently saw similar symptoms on a Kamailio 4.0.4 server, but Kamailio unfortunately crashed before I could get further details. In this case, I can consistently duplicate the problem with certain INVITEs. It seems that the failure is somehow related to the size of the SIP headers. For example, I have an INVITE from a Polycom phone which t_relay() routes successfully with 741 bytes of headers (total SIP length 1039 bytes). However, it seems that if I add one character to any of its SIP headers (742 bytes of headers; total SIP length 1039 bytes) the t_relay() will consistently fail.<br>

<br>
This binary doesn't have DBG_QM_MALLOC configured (I am working on getting it re-compiled). However, since I don't know what caused the problem, I would still like to get as much information as I can out of the running system. I have attached the output of mi_statistics, as well as mem_dump_pkg for the external UDP receivers and the ctl handler. Are there any other diagnostics that could be useful?<br>

<br>
<br>
-Andrew<br>
<br>
<br>
[1] <a href="http://www.kamailio.org/dokuwiki/doku.php/troubleshooting:faq#qwhat_does_errorsip_msg_clonercannot_allocate_memory_and_errornew_tout_of_memmean_and_how_do_i_fix_them" target="_blank">http://www.kamailio.org/<u></u>dokuwiki/doku.php/<u></u>troubleshooting:faq#qwhat_<u></u>does_errorsip_msg_<u></u>clonercannot_allocate_memory_<u></u>and_errornew_tout_of_memmean_<u></u>and_how_do_i_fix_them</a><br>

<br>_______________________________________________<br>
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list<br>
<a href="mailto:sr-users@lists.sip-router.org">sr-users@lists.sip-router.org</a><br>
<a href="http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users" target="_blank">http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users</a><br>
<br></blockquote></div><br></div>