<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
Hello,<br>
<br>
I don't remember any similar reported issues in 4.0, but in general,
it is easier to troubleshoot with the latest version in the branch.
Using the latest 4.0.x will solve other issues that might hit you.<br>
<br>
I still have couple of 4.0 in production, not started for more than
half an year, with all traffic on a virtual ip managed by ucarp.<br>
<br>
Kamailio itself cannot mess the buffer, because it reads an UDP
packet at a time, which is one sip packet and then if it is broken,
it is discarded. There is no queuing inside kamailio for udp
packets. Also, the UDP fragmentation is handled by the OS/Kernel,
not by kamailio. So it might worth checking there are no barriers in
the OS.<br>
<br>
I have to say that the OSes I mainly work with are Debian based
(Debian or Ubuntu). I know that CentOS enables selinux by default
which has tons of limits -- if you use it, consider disabling
selinux and see if goes better.<br>
<br>
Cheers,<br>
Daniel<br>
<br>
<div class="moz-cite-prefix">On 03/04/15 13:04, Yufei Tao wrote:<br>
</div>
<blockquote
cite="mid:CAJwP0iTBGk8S91CheS+xAON2fJgyKZH9HFcwTbvcLygmzLNd+g@mail.gmail.com"
type="cite">
<div dir="ltr">
<div>
<div>
<div>
<div>
<div>Hi Daniel<br>
<br>
</div>
<div>We don't have pike module enabled.<br>
<br>
</div>
When the problem occurred on an VIP, we observed these:
<br>
* Kamailio stopped responding to any messages that were
sent to the VIP, not just OPTIONS<br>
* The OPTIONS messages are not big. But the other SIP
messages, e.g. some of the INVITE/OK that came from some
SBCs can be big<br>
</div>
* netstat showed the Recv-Q on that VIP had a lot of bytes
accumulated, while Kamailio was not seeing/reading them<br>
</div>
* Kamailio responded fine on its real IP, when I sent
OPTIONS pings to it using sipsak<br>
</div>
<div>* After restarting Kamailio it started working. But after
1 week or so the same problem happened again<br>
</div>
<div><br>
</div>
<div>Since this only happened after running for 1 week or so,
we didn't have any traces to show what exactly happened at
the particular time when it happened. It is possible some
SIP messages may have come in fragmented and some are just
too big, depending on the route they came from etc. So I was
wonder if it was possible that the UDP receive buffer was
filled somehow with messed-up messages. Is there anyway to
check this? Any suggestions where I should start looking
please? Or is it generally a bad idea to use UDP when there
are messages that may be too big, either fragmented or not?<br>
<br>
</div>
<div>Since the it is running in the production environment,
I'd like to get some confidence that a Kamailio upgrade will
fix the problem first before I change anything there.<br>
</div>
<div><br>
</div>
Cheers,<br>
</div>
Yufei<br>
<div>
<div>
<div>
<div>
<div>
<div><br>
<br>
<div><br>
Date: Wed, 01 Apr 2015 16:27:44 +0200<br>
From: Daniel-Constantin Mierla <<a
moz-do-not-send="true"
href="mailto:miconda@gmail.com">miconda@gmail.com</a>><br>
To: "Kamailio (SER) - Users Mailing List"<br>
<<a moz-do-not-send="true"
href="mailto:sr-users@lists.sip-router.org">sr-users@lists.sip-router.org</a>
<div id=":v1" class="">><br>
Subject: Re: [SR-Users] SIP messages over UDP
with sizes over MTU<br>
Message-ID: <<a moz-do-not-send="true"
href="mailto:551C0060.3010002@gmail.com">551C0060.3010002@gmail.com</a>><br>
Content-Type: text/plain; charset="windows-1252"<br>
<br>
Hello,<br>
<br>
first, not related to the topic you reported, I
would recommend at least<br>
upgrading to latest 4.0.x, there were many fixes
from v4.0.0 and there<br>
are no changes to be done to config or database
-- simply deploy latest<br>
4.0.x and restart.<br>
<br>
Back to this topic. Is all the other traffic
handled apart of big OPTIONS?<br>
<br>
Do you have pike module enabled? If yes, can you
double check and be<br>
sure that the SBC is not blacklisted (traffic
from it should not be<br>
handled via pike_check_req()).<br>
<br>
Cheers,<br>
Daniel<br>
<br>
On 01/04/15 15:42, Yufei Tao wrote:<br>
> Hi<br>
><br>
> We've got Kamailio (v4.0.0) connected to
some SBC, which sends SIP<br>
> traffic and periodic OPTIONS pings to
Kamailio's VIP. Kamailio<br>
> responds to the OPTIONS pings with OK, i.e.
in the main route block:<br>
> if (is_method("OPTIONS"))<br>
> {<br>
> sl_send_reply("200","OK");<br>
> exit;<br>
> }<br>
><br>
> All works fine for a week or so, then
Kamailio stopped responding to<br>
> the OPTIONS pings on the VIP it listens to.
But it still respond to<br>
> OPTIONS pings that are sent to its real IP.
The real IP is not used<br>
> for receiving/sending any traffic while
only the VIP is. So it seems<br>
> that Kamailio is still working, but maybe
having problems with the<br>
> receiving buffer for the VIP?<br>
><br>
> We do see that some SIP messages sent to
Kamailio's VIP are too big<br>
> (sometimes over 1500 bytes). My question
is, in this case, what would<br>
> be expected to happen? Is it possible
somehow the receiving buffer for<br>
> the VIP got messed up by the big UDP
messages? Any one seen similar<br>
> problems? What is the suggested solution?<br>
><br>
> We're considering moving to TCP. But since
this is production<br>
> environment, I want to get some confidence
that the problem we saw was<br>
> likely to have been caused by the UDP
message being too large.<br>
><br>
> Cheers,<br>
> Yufei</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
<a class="moz-txt-link-abbreviated" href="mailto:sr-users@lists.sip-router.org">sr-users@lists.sip-router.org</a>
<a class="moz-txt-link-freetext" href="http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users">http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users</a>
</pre>
</blockquote>
<br>
<pre class="moz-signature" cols="72">--
Daniel-Constantin Mierla
<a class="moz-txt-link-freetext" href="http://twitter.com/#!/miconda">http://twitter.com/#!/miconda</a> - <a class="moz-txt-link-freetext" href="http://www.linkedin.com/in/miconda">http://www.linkedin.com/in/miconda</a>
Kamailio World Conference, May 27-29, 2015
Berlin, Germany - <a class="moz-txt-link-freetext" href="http://www.kamailioworld.com">http://www.kamailioworld.com</a></pre>
</body>
</html>