Domenico,
Can I reproduce this then by using sipp over TCP transport and kill both
sipp-uac and sipp-uas by sending SIGKILL (This will put the sockets in
an unknown state)?
Although I agree in the design philosophy you have proposed, to patch
sipXtackLib, we need to adhere to an acceptance
I'm speaking of self protect .. a server can't be undermined by a poorly
written client.
the situation here is a server with 50 users that sends to me allarms every
5 minutes 'cause proxy is at 300% of cpu usage.
On Tue, Nov 13, 2012 at 5:40 PM, Tony Graziano wrote:
> does it make sense for us
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
writte
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
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 s
Just to simplify tests here is the patch
On Tue, Nov 13, 2012 at 3:14 PM, Domenico Chierico
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
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 SUBSC
There is a mix up. The fix is with 4.6 and it is for calls from a trunk
provider to sipX traversing sipXbridge. In your case, the call is from
internal phone towards the ITSP and you are asking whether it is
possible to play MoH instead of hearing actual ring, then the answer to
that is no.
