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
------------------------------------------------------------------------- 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
