yes, -inf was broken in case of auto answered messages. I kept the solution you suggesting by exposing m_counter, I think it's OK now (SVN 44).
For the issue with messages received after the end of the scenario, I think it's OK to have this pause. I have not a lot of time to look at it, but can you tell me what error is displayed when those messages are received during the pause?
For the display of auto-answered messages, I'll try to see what is possible.
Olivier.
On 9/21/06, Victor L <
[EMAIL PROTECTED]> wrote:
Hey Tarek,With the latest load, all NOTIFYs do get answered if I add a "pause" at the end of my scenario. However, these NOTIFYs are treated as errors and are logged to the error logs (not too much of a problem, though).Vic
On 9/21/06, F. Tarek Rogers < [EMAIL PROTECTED]> wrote:-------------------------------------------------------------------------
Hi Olivier,
have you given any thought to m_counter change below?
The pause issue is a more complicated issue, but sipp is currently broken with inf files and -aa.
Thanks
> This one is better, only -m calls are generated, but the m_counter
> value for selecting the line number of the CSV/INFO file is being
> incremented (by the call constructor). So, if I receive 3 unexpected
> NOTIFYs in call 1, my second call uses line 5 of the CSV instead of
> line 2 ;)
> I moved m_counter to the public section of the call class and added
> call::m_counter--;
> to your delete_call section in sipp.c and it fixed that issue - but
> there might be a better way than exposing m_counter...
>
> Second issue:
>
> This is a new scenario, close to the one Victor mentioned, where a
> UAC sends a REG/PUB/SUB and receives multiple NOTIFYs to the SUB. If
> I just run that scenario, -aa works pretty good. It however fails to
> respond to the last NOT of the last call, because the expected
> messages have all been received, and SIPp exists. Normally not a big
> deal, except out proxy sends a timeout back to the presence server,
> who promptly tears down that subscription.
>
> So, to fix that, I added a pause statement at the end of the XML, so
> that any lagging NOTs would be caught and auto-answered before the
> call/sipp exited. Oddly - with the pause statement, none of the NOTs
> were auto-answered. It's looks like -aa code is not being executed
> when SIPp is in a pause command. Perhaps thats the intended nature
> of pause... but it might be problematic with -aa.
>
> Third - and this is a wish-list item, since you've been so kind to
> get this feature working ;) I would love to see a statistic counter
> for auto-answered items in either the Scenario Screen or the
> Statistics Screen. That way we can verify we received the correct
> number of NOTs during a login run. I might could add that myself if
> it's time consuming, but I've not looked at that code yet.
>
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net 's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Sipp-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/sipp-users
--
HP OpenCall Software
http://www.hp.com/go/opencall/
------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________ Sipp-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/sipp-users
