Hi Daniel

Thanks for the reply! Here are things we use:
* keepalived for HA
* Ubuntu 12.04
There seems to be problems when Kamailio operates on both UDP and TCP at the same time. But I'll upgrade Kamailio from v4.0.0. to v4.0.7 first and see what we get, since there are a few bug fixes to do with TCP between these two versions.

Cheers,
Yufei

On 4 April 2015 at 11:00, <sr-users-request@lists.sip-router.org> wrote:
Send sr-users mailing list submissions to
        sr-users@lists.sip-router.org

To subscribe or unsubscribe via the World Wide Web, visit
        http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
or, via email, send a message with subject or body 'help' to
        sr-users-request@lists.sip-router.org

You can reach the person managing the list at
        sr-users-owner@lists.sip-router.org

When replying, please edit your Subject line so it is more specific
than "Re: Contents of sr-users digest..."


Today's Topics:

   1. Re: SIP messages over UDP with sizes over MTU (Yufei Tao)
   2. Re: SIP messages over UDP with sizes over MTU
      (Daniel-Constantin Mierla)


----------------------------------------------------------------------

Message: 1
Date: Fri, 3 Apr 2015 12:04:49 +0100
From: Yufei Tao <yufei.tao@gmail.com>
To: sr-users@lists.sip-router.org
Subject: Re: [SR-Users] SIP messages over UDP with sizes over MTU
Message-ID:
        <CAJwP0iTBGk8S91CheS+xAON2fJgyKZH9HFcwTbvcLygmzLNd+g@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"

Hi Daniel

We don't have pike module enabled.

When the problem occurred on an VIP, we observed these:
* Kamailio stopped responding to any messages that were sent to the VIP,
not just OPTIONS
* 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
* netstat showed the Recv-Q on that VIP had a lot of bytes accumulated,
while Kamailio was not seeing/reading them
* Kamailio responded fine on its real IP, when I sent OPTIONS pings to it
using sipsak
* After restarting Kamailio it started working. But after 1 week or so the
same problem happened again

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?

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.

Cheers,
Yufei



Date: Wed, 01 Apr 2015 16:27:44 +0200
From: Daniel-Constantin Mierla <miconda@gmail.com>
To: "Kamailio (SER) - Users Mailing List"
        <sr-users@lists.sip-router.org
>
Subject: Re: [SR-Users] SIP messages over UDP with sizes over MTU
Message-ID: <551C0060.3010002@gmail.com>
Content-Type: text/plain; charset="windows-1252"

Hello,

first, not related to the topic you reported, I would recommend at least
upgrading to latest 4.0.x, there were many fixes from v4.0.0 and there
are no changes to be done to config or database -- simply deploy latest
4.0.x and restart.

Back to this topic. Is all the other traffic handled apart of big OPTIONS?

Do you have pike module enabled? If yes, can you double check and be
sure that the SBC is not blacklisted (traffic from it should not be
handled via pike_check_req()).

Cheers,
Daniel

On 01/04/15 15:42, Yufei Tao wrote:
> Hi
>
> We've got Kamailio (v4.0.0) connected to some SBC, which sends SIP
> traffic and periodic OPTIONS pings to Kamailio's VIP. Kamailio
> responds to the OPTIONS pings with OK, i.e. in the  main route block:
>    if (is_method("OPTIONS"))
>    {
>       sl_send_reply("200","OK");
>       exit;
>    }
>
> All works fine for a week or so, then Kamailio stopped responding to
> the OPTIONS pings on the VIP it listens to. But it still respond to
> OPTIONS pings that are sent to its real IP. The real IP is not used
> for receiving/sending any traffic while only the VIP is. So it seems
> that Kamailio is still working, but maybe having problems with the
> receiving buffer for the VIP?
>
> We do see that some SIP messages sent to Kamailio's VIP are too big
> (sometimes over 1500 bytes). My question is, in this case, what would
> be expected to happen? Is it possible somehow the receiving buffer for
> the VIP got messed up by the big UDP messages? Any one seen similar
> problems? What is the suggested solution?
>
> We're considering moving to TCP. But since this is production
> environment, I want to get some confidence that the problem we saw was
> likely to have been caused by the UDP message being too large.
>
> Cheers,
> Yufei
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sip-router.org/pipermail/sr-users/attachments/20150403/99203242/attachment-0001.html>

------------------------------

Message: 2
Date: Fri, 03 Apr 2015 19:23:35 +0200
From: Daniel-Constantin Mierla <miconda@gmail.com>
To: "Kamailio (SER) - Users Mailing List"
        <sr-users@lists.sip-router.org>
Subject: Re: [SR-Users] SIP messages over UDP with sizes over MTU
Message-ID: <551ECC97.7060600@gmail.com>
Content-Type: text/plain; charset="windows-1252"

Hello,

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.

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.

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.

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.

Cheers,
Daniel

On 03/04/15 13:04, Yufei Tao wrote:
> Hi Daniel
>
> We don't have pike module enabled.
>
> When the problem occurred on an VIP, we observed these:
> * Kamailio stopped responding to any messages that were sent to the
> VIP, not just OPTIONS
> * 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
> * netstat showed the Recv-Q on that VIP had a lot of bytes
> accumulated, while Kamailio was not seeing/reading them
> * Kamailio responded fine on its real IP, when I sent OPTIONS pings to
> it using sipsak
> * After restarting Kamailio it started working. But after 1 week or so
> the same problem happened again
>
> 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?
>
> 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.
>
> Cheers,
> Yufei
>
>
>
> Date: Wed, 01 Apr 2015 16:27:44 +0200
> From: Daniel-Constantin Mierla <miconda@gmail.com
> <mailto:miconda@gmail.com>>
> To: "Kamailio (SER) - Users Mailing List"
>         <sr-users@lists.sip-router.org
> <mailto:sr-users@lists.sip-router.org>
> >
> Subject: Re: [SR-Users] SIP messages over UDP with sizes over MTU
> Message-ID: <551C0060.3010002@gmail.com
> <mailto:551C0060.3010002@gmail.com>>
> Content-Type: text/plain; charset="windows-1252"
>
> Hello,
>
> first, not related to the topic you reported, I would recommend at least
> upgrading to latest 4.0.x, there were many fixes from v4.0.0 and there
> are no changes to be done to config or database -- simply deploy latest
> 4.0.x and restart.
>
> Back to this topic. Is all the other traffic handled apart of big OPTIONS?
>
> Do you have pike module enabled? If yes, can you double check and be
> sure that the SBC is not blacklisted (traffic from it should not be
> handled via pike_check_req()).
>
> Cheers,
> Daniel
>
> On 01/04/15 15:42, Yufei Tao wrote:
> > Hi
> >
> > We've got Kamailio (v4.0.0) connected to some SBC, which sends SIP
> > traffic and periodic OPTIONS pings to Kamailio's VIP. Kamailio
> > responds to the OPTIONS pings with OK, i.e. in the  main route block:
> >    if (is_method("OPTIONS"))
> >    {
> >       sl_send_reply("200","OK");
> >       exit;
> >    }
> >
> > All works fine for a week or so, then Kamailio stopped responding to
> > the OPTIONS pings on the VIP it listens to. But it still respond to
> > OPTIONS pings that are sent to its real IP. The real IP is not used
> > for receiving/sending any traffic while only the VIP is. So it seems
> > that Kamailio is still working, but maybe having problems with the
> > receiving buffer for the VIP?
> >
> > We do see that some SIP messages sent to Kamailio's VIP are too big
> > (sometimes over 1500 bytes). My question is, in this case, what would
> > be expected to happen? Is it possible somehow the receiving buffer for
> > the VIP got messed up by the big UDP messages? Any one seen similar
> > problems? What is the suggested solution?
> >
> > We're considering moving to TCP. But since this is production
> > environment, I want to get some confidence that the problem we saw was
> > likely to have been caused by the UDP message being too large.
> >
> > Cheers,
> > Yufei
>
>
> _______________________________________________
> SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
> sr-users@lists.sip-router.org
> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users

--
Daniel-Constantin Mierla
http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
Kamailio World Conference, May 27-29, 2015
Berlin, Germany - http://www.kamailioworld.com

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sip-router.org/pipermail/sr-users/attachments/20150403/a32b7130/attachment-0001.html>

------------------------------

Subject: Digest Footer

_______________________________________________
sr-users mailing list
sr-users@lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users


------------------------------

End of sr-users Digest, Vol 119, Issue 4
****************************************