On 24 March 2013 16:44, Matt Chung <itsmemattch...@gmail.com> wrote: > The calls were failing due to the TCP socket timing out, therefore I > subsequently enabled the flag "-reconnect_close false" which allowed SIPp to > wait for the incoming UPDATE.
Hmm, trace_err (or even stderr) really ought to give better diagnostics there. I'll add it to my TODO list - thanks for tracking down that omission. > This makes sense since the TCP connection was originally SIPP:ephermeral> > UAS:5060, and now it is the UAS:ephermal > SIPp:5060 for the new connection. > I've attempted to work around this by executing the SIPp application as a > UAC, exiting SIPp, then immediately opening up another instance of SIPp as a > UAS to wait for the incoming UPDATE. I'm curious (though I don't use SIP over TCP much at all, so perhaps I'm missing something). What would a genuine client do differently from SIPp in this situation? Surely it wouldn't always be able to listen on port 5060 for an incoming UPDATE? If that's so, and genuine clients would also find their connections dropping after two minutes, then perhaps you want to focus on avoiding the timeout entirely (perhaps by tweaking your TCP keepalive settings on the UAS). ------------------------------------------------------------------------------ Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_mar _______________________________________________ Sipp-users mailing list Sipp-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sipp-users
