[SR-Users] SIP messages over UDP with sizes over MTU
miconda at gmail.com
Wed Apr 1 16:27:44 CEST 2015
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()).
On 01/04/15 15:42, Yufei Tao wrote:
> 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"))
> 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.
> SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
> sr-users at lists.sip-router.org
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...
More information about the sr-users