With the latest SVN, here is what I found:
1. In my scenarios, I received 2 NOTIFY messages in between other types of messages. The second NOTIFY was received at the very end. However, only 1 "200 OK" was sent out and that was for the 2nd NOTIFY message! So, the first NOTIFY did not get any response.
2. I also ran into the problem that Tarek mentioned about NOTIFY messages being ignored at the end; same problem with inserting pause at the end as well. Can we add something like the "nop" command, or maybe even an attribute to the "nop" command which will wait for the user to end the program, and meanwhile, either do nothing, or automatically reply to INFO, NOTIFY, etc messages in the -aa mode?
Thank,
Vic
On 9/7/06, F. Tarek Rogers <[EMAIL PROTECTED]> wrote:
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.
t
> Can you try again with the latest SVN?
> http://sipp.sourceforge.net/snapshots/sipp.2006-09-07.tar.gz
>
> Should be ok.
> Olivier.
>
> On 9/7/06, Olivier Jacques <[EMAIL PROTECTED]> wrote:
>>
>> This was a quick an unfortunate solution. What you see is because I
>> created a call for the incoming message (SIPp, in client mode is
>> receiving a
>> msg with an unknown call-id (that it didn't generated)). Of course,
>> creating
>> a new call (when SIPp is a client), triggers the execution of a scenario:
>> this is why you see 2 calls going out.
>> Just for the auto-answer of async messages, I will just send the 200
>> message without any scenario...
>>
>> Olivier.
>>
>>
>> On 9/7/06, F. Tarek Rogers < [EMAIL PROTECTED]> wrote:
>>>
>>>
>>> Well, this is strange... I have a simple setup where user 'sep1' has
>>> subscribed to 'sep2'. Then I use the attached XML to send a PUBLISH as
>>> 'sep2', which results in a NOTIFY being sent to 'sep1' (which,
>> incidentally,
>>> is the same server - so the sep2 scenario receives the
>> 'unexpected' notify)
>>>
>>> With your snapshot, I see 2 oddities. First, the scenario is generating
>>> 2 calls, despite the -m 1 parameter used. Secondly - although
>> auto-answer
>>> is correctly sending a OK to the first unexpected NOTIFY, the second is
>>> simply ignored. (I have a pause statement at the end of the scenario to
>>> make sure the NOTIFY is received by SIPp before it exits)
>>>
>>> Attaching relevant files.
>>>
>>> > Tarek, User (whatever your name could be :) ),
>>> >
>>> > could you try the latest svn with -aa (
>>> > http://sipp.sourceforge.net/snapshots/sipp.2006-09-06.tar.gz) and
>>> report?
>>> > I just authorized SIPp to handle messages with unknown call-ids,
>>> through
>>> > "-aa".
>>> >
>>> > @User,
>>> > thanks for the kudos, this is always nice...
>>> >
>>> > Olivier.
>>> >
>>>
>>> [EMAIL PROTECTED] sipp.2006-09-06]# ./sipp 67.1.100.93:5060 -inf
>>> uc-8-publish.dat -sf uc-8-publish.xml -t t1 -m 1 -aa -trace_msg
>>>
>>> Resolving remote host ' 67.1.100.93'... Done.
>>> ------------------------------ Scenario Screen -------- [1-5]: Change
>>> Screen --
>>> Call-rate(length) Port Total-time Total-calls Remote-host
>>> 10.0(0 ms)/1.000s 5060 10.29 s 2 67.1.100.93:5060
>>> (TCP)
>>>
>>> Call limit reached (-m 1), 0.294 s period 1 ms scheduler resolution
>>> 0 concurrent calls (limit 300) Peak was 2 calls, after 0 s
>>> 0 out-of-call msg (discarded)
>>> 3 open sockets
>>>
>>> Messages Retrans Timeout
>>> Unexpected-Msg
>>> PUBLISH ----------> 2 0
>>> 100 <---------- 2 0 0
>>> 200 <---------- 2 0 0
>>> Pause [ 10000ms] 2 0
>>> ------------------------------ Test Terminated
>>> --------------------------------
>>>
>>>
>>>
>>>
>>>
>>>
>>
>>
>> --
>> HP OpenCall Software
>> http://www.hp.com/go/opencall/
--------------------------------------------------------------------------
:: F. Tarek Rogers :: [EMAIL PROTECTED] :: echo '[dO%O+3E%O+PO/d0<0]\
Fi22os0302E554A6CCBCBAB0079639705881B3BCD79B52636A81C0D9E025134C3l0xAP'|dc
------------------------------------------------------------------------- Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________ Sipp-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/sipp-users
