does it make sense for us to try to build the proxy up to fix UA's that might be considered a little more than misguided in the way they handle transactions? I don't disagree with the concept of trying to fix it, I just wonder if we head down a path of no-return by having to deal with poorly written ua's...
On Tue, Nov 13, 2012 at 10:48 AM, Domenico Chierico < [email protected]> wrote: > Hi Joegen > > In more genereical way I've found that we have a problem with > uncorrectly closed socket from UA, this can be seen with an unfinished > sip stack that ends prematurely and with some softphone that crash or > (like linphone) allow to change the transport protocol on fly. > > Using many different softphone make our server behave as I described, > with this patch seems that things go better. > > I'm still testing so this aren't final results, what I really like to > know is your opinion about the validity of the approach, basically I > think that check if socket is broken before read or write on it seems > to be more safe way of manage. > Do you agree ? > > > On Tue, Nov 13, 2012 at 4:09 PM, Joegen Baclor <[email protected]> wrote: > > Domenico, > > > > Thanks for the patch. Just clarifying, this patch is for the behavior > you > > specified in the August 3 post? If I'm correct, All I need to do to > > reproduce is send an INVITE using TCP, on receipt of 183, close the > socket. > > > > -j > > > > > > On 11/13/2012 10:53 PM, Domenico Chierico wrote: > > > > Just to simplify tests here is the patch > > > > On Tue, Nov 13, 2012 at 3:14 PM, Domenico Chierico > > <[email protected]> wrote: > > > > Hi > > We have 1 sipxecs 4.4 with 50 users installed on kvm based virtual > machine. > > We had the proxy that ran over 290% of cpu with an average cpu load > > close to 95%. Applying the review #22, the stuff start goes better and > > we are now close to 40% of cpu load. > > > > Some of this load come from the known SUBSCRIBE issue, but some others > > come from a strange behaviour of the tcp part of the sip stack that we > > found: > > > > - linphone client increases the load on sipXproxy, with his own > > strange keepalive method ("Jak" msg to the proxy) and switching the > > transport from tcp to udp. > > > > - Some other evidences come from my personal tests as I notify on 3 of > > August on dev-ml. > > > > Now I'm testing a solution that seems to work, but I wish to know your > > opinion. I've change the order of "if" statements into SipClient::run > > and I moved the branch about POLLERR and POLLHUP as first. > > > > On Fri, Aug 3, 2012 at 11:43 AM, Domenico Chierico > > <[email protected]> wrote: > > > > I'm just playing around with go(lang), and this days I was starting > > with sip stack implementation, just when messages starts float around > > I'd realize that I've written a DOS for proxy .. > > I just send INVITE to the proxy than reads for 100 and 180 and so I > > close the socket, at this point I got this into the logs forever: > > > > "2012-08-03T09:31:03.817653Z":43810:SIP:DEBUG:testpbx.labsip2ser.net: > SipClientTcp-30:22CEF700:SipXProxy:"SipClient[SipClientTcp-30]::run > > resPoll= 1 revents: fd[0]= 0 fd[1]= 1d" > > "2012-08-03T09:31:03.817668Z":43811:KERNEL:DEBUG:testpbx.labsip2ser.net: > SipClientTcp-30:22CEF700:SipXProxy:"OsSocket::isReadyToWrite > > poll returned 1 in socket: 21 0x7f5eec002070" > > "2012-08-03T09:31:03.817683Z":43812:SIP:DEBUG:testpbx.labsip2ser.net: > SipClientTcp-30:22CEF700:SipXProxy:"SipClient[SipClientTcp-30]::run > > resPoll= 1 revents: fd[0]= 0 fd[1]= 1d" > > "2012-08-03T09:31:03.817698Z":43813:KERNEL:DEBUG:testpbx.labsip2ser.net: > SipClientTcp-30:22CEF700:SipXProxy:"OsSocket::isReadyToWrite > > poll returned 1 in socket: 21 0x7f5eec002070" > > "2012-08-03T09:31:03.817714Z":43814:SIP:DEBUG:testpbx.labsip2ser.net: > SipClientTcp-30:22CEF700:SipXProxy:"SipClient[SipClientTcp-30]::run > > resPoll= 1 revents: fd[0]= 0 fd[1]= 1d" > > "2012-08-03T09:31:03.817728Z":43815:KERNEL:DEBUG:testpbx.labsip2ser.net: > SipClientTcp-30:22CEF700:SipXProxy:"OsSocket::isReadyToWrite > > poll returned 1 in socket: 21 0x7f5eec002070" > > > > I hope this helps.. > > > > bye > > Domenico Chierico > > > > > > > > _______________________________________________ > > sipx-users mailing list > > [email protected] > > List Archive: http://list.sipfoundry.org/archive/sipx-users/ > > > > > _______________________________________________ > sipx-users mailing list > [email protected] > List Archive: http://list.sipfoundry.org/archive/sipx-users/ > -- ~~~~~~~~~~~~~~~~~~ Tony Graziano, Manager Telephone: 434.984.8430 sip: [email protected] Fax: 434.465.6833 ~~~~~~~~~~~~~~~~~~ Linked-In Profile: http://www.linkedin.com/pub/tony-graziano/14/4a6/7a4 Ask about our Internet Fax services! ~~~~~~~~~~~~~~~~~~ Using or developing for sipXecs from SIPFoundry? Ask me about sipX-CoLab 2013! <http://sipxcolab2013.eventbrite.com/?discount=tony2013> -- LAN/Telephony/Security and Control Systems Helpdesk: Telephone: 434.984.8426 sip: [email protected] Helpdesk Customers: http://myhelp.myitdepartment.net Blog: http://blog.myitdepartment.net
_______________________________________________ sipx-users mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipx-users/
