From: mayamatakeshi [mailto:mayamatake...@gmail.com]
On Fri, Feb 25, 2011 at 12:11 AM, John McNamara <john.mcnam...@emutex.com> wrote: From: John McNamara [mailto:john.mcnam...@emutex.com] >> I can't get the timeout to work with a recv message in a simplified server scenario such as the following: >> I never use this. But the behavior you describe looks reasonable to me (not a bug). >> Why would you want it to timeout before receiving the initial message? Hi, I want it to timeout before receiving an initial message in case it *never* receives an initial message. I am testing a scenario where 2 SIPp instances are simulating both ends of a call with the system under test in the middle. If the A party call fails then the SIPp scenario will fail and we can catch the failure under automated testing. However, in this case the B party SIPp instance won't receive an initial INVITE and will continue running indefinitely. It seems reasonable (to me) to expect the recv timeout to work regardless of its position in the call flow. It isn't documented that it doesn't work that way. So to me this looks like a bug. If it is then I'll try fix it. If it isn't then I'll work around it. John.
------------------------------------------------------------------------------ Free Software Download: Index, Search & Analyze Logs and other IT data in Real-Time with Splunk. Collect, index and harness all the fast moving IT data generated by your applications, servers and devices whether physical, virtual or in the cloud. Deliver compliance at lower cost and gain new business insights. http://p.sf.net/sfu/splunk-dev2dev
_______________________________________________ Sipp-users mailing list Sipp-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sipp-users
