Hello Folks.
According the new update on Feb 5, 2014, IBM has implemented proxy managed
overload protection (PMOP) at SIP proxy server.
http://pic.dhe.ibm.com/infocenter/wasinfo/v7r0/index.jsp?topic=%2Fcom.ibm.websphere.nd.doc%2Finfo%2Fae%2Fae%2Fcjpx_sippxovldpro.html
The above IBM link lists
Hello Folks.
The presentation slides for two implicit SIP overload control algorithms (RRRC
and RTDC) are available for your download.
Redundant Retransmission Ratio Control (RRRC) - implicit SIP overload control
algorithm (IEEE Globecom 2010 Slides) can be downloaded from the following
Hello Folks.
SIP faces with overload issue recently due to its popularity. Build-in
overload mechanism cannot prevent overload effectively. Therefore, IETF SIP
Overload Control (soc) Working Group works on IETF RFC SIP Overload Control
currently.
: Re: [SR-Users] Max concurrent TCP connection that Kamailio support ?
Hi Yang Hong, thanks for your reply and those papers
1. When client make TCP connection, it usually get [FIN,ACK] and [RST] from
server. Does that mean that server has reach max TCP connection limit, or
server is busy handling
Sorry to hear this really negative news on open-source Kamailio. I want to
share the following two good articles with you. Both articles shed light on the
positive impact of building with SIP. The 1st good article H.323 and SIP
Becoming Legacy. XMPP and JS are the Future
April 12, 2012
The 12
Yes. You can set it to 256K connections. However, Kamailio node may exhibit
overload even collapse, when maximum 256K TCP connections reaches and each
connection perform heavy task by average. To be conservative, you can collect
statistics about CPU and memory utilization of Kamailio node
Dear all,
SIP overload may block too many calls unnecessarily.
Requirements for Management of Overload in the Session Initiation Protocol.
IETF RFC 5390.
http://www.ietf.org/rfc/rfc5390.txt Build-in overload mechanism cannot prevent
overload effectively. Therefore, IETF SIP Overload Control
Dear all, Kaplan, Michael A wrote:
Sure - I'm referring to mechanisms for the server to advertise to upstream
neighbors to reduce request rates. This could include methods that appear
in RFC 6357 (e.g. rate-limits, window-based control, loss-rate enforcement).
I suppose the
Hello. SIP over TCP would reduce server performance significantly when compared
with SIP Over UDP. Please read the following two papers. Combining RTP proxy
with SIP over TCP would degrade SIP server performance even worse.
