Hi Charles, yes, I'll have a look to see what the code does.
But do you agree that with ... <recv response="401" auth="true" optional="true" timeout="5000"> </recv> <recv response="480" timeout="10000" optional="false"> </recv> ... and the 401 has received within timeout="5000" the next expected message is a 480 with a timeout of "10000" (and not "5000") ? So while there is no message incoming any more after the 401, sipp should wait 10 seconds for 480, right ? Cheers, Frederic On Fr, 2008-01-25 at 13:05 -0500, Charles P Wright wrote: > Frederic, > > I believe after receiving the 401, a second 401 is allowed to be received > which is why the 5s timeout is used. The call::run and > call::process_incoming functions are where you should look to analyze the > behavior more deeply. The "dump tasks" command may also provide you some > insight (press 'c' to be able to enter it). > > Charles > > Frederic-Philippe Metz <[EMAIL PROTECTED]> wrote on 01/25/2008 > 12:02:04 PM: > > > Hi Charles, > > > > okay, but the point here is that there's an individual timeout of 5 > > seconds on the 401 Response and a 10 seconds timeout on the 480. > > Sipp gets the 401 but times out after 5 seconds of not receiving the > > 480. I would expect sipp to timeout after the configured timeout of > > 10 seconds on the 480 ? > > > > The five seconds timeout for the 401 should have been thrown away > > after receiving the 401 within 5 seconds. > > > > Cheers, > > Frédéric > > > > > > On Fr, 2008-01-25 at 10:29 -0500, Charles P Wright wrote: > > > The -timeout option will simply cause SIPp to exit after a certain > amount > > > of time. The -recv_timeout option is applied only to messages that do > not > > > have an explicit timeout specified in the XML. > > > > > > The first timeout is taken for a sequence of messages. As SIPp > doesn't > > > have a notion of transactions, it isn't aware that the transaction is > > > finished. You need to set an explicit next label in the 401 and jump > to > > > sending the authenticated register. > > > > > > Charles > > > > > > [EMAIL PROTECTED] wrote on 01/25/2008 10:22:59 > AM: > > > > > > > Hi, > > > > > > > > Szenario: > > > > > > > > <scenario name="Register, reply 200 Ok"> > > > > <send> > > > > <![CDATA[ > > > > > > > > > > > > REGISTER sip:[host_part] SIP/2.0 > > > > To: [display_name]<sip:[EMAIL PROTECTED]> > > > > From: > > > > [display_name]<sip:[EMAIL PROTECTED]>;tag=[call_number] > > > > Via: SIP/2.0/[transport] [local_ip]:[local_port] > > > > Call-ID: [call_id] > > > > Cseq: 1 REGISTER > > > > Contact: <sip:[EMAIL PROTECTED]:[local_port]> > > > > Expires: 100 > > > > Max-Forwards: 70 > > > > Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY, > MESSAGE, > > > > SUBSCRIBE, INFO > > > > User-Agent: SIPp [display_name] sip:[EMAIL PROTECTED] > > > > Content-Length: [len] > > > > > > > > > > > > ]]> > > > > </send> > > > > > > > > > > > > <recv response="401" auth="true" optional="true" timeout="5000"> > > > > </recv> > > > > > > > > > > > > <recv response="480" timeout="10000" optional="false"> > > > > </recv> > > > > ... > > > > > > > > > > > > Output, regardless -timeout or -recv_timeout is specified or not: > > > > > > > > > > > > ------------------------------ Scenario Screen -------- [1-9]: > Change > > > > Screen -- > > > > Call-rate(length) Port Total-time Total-calls Remote-host > > > > 10.0(0 ms)/1.000s 20910 5.11 s 1 > > > > 1.2.3.154:5060(UDP) > > > > > > > > > > > > Call limit reached (-m 1), 0.108 s period 3 ms scheduler > resolution > > > > 0 calls (limit 30) Peak was 1 calls, after 0 s > > > > 0 Running, 0 Paused, 1 Woken up > > > > 0 out-of-call msg (discarded) > > > > 1 open sockets > > > > > > > > > > > > Messages Retrans Timeout > > > > Unexpected-Msg > > > > REGISTER ----------> 1 0 > > > > 401 <---------- 1 0 1 0 > > > > 480 <---------- 0 0 0 0 > > > > REGISTER ----------> 0 0 0 > > > > 200 <---------- 0 0 0 0 > > > > ------------------------------ Test Terminated > > > > -------------------------------- > > > > > > > > > > > > And finally, the SIP message log: > > > > > > > > > > > > ----------------------------------------------- 2008-01-24 > > > > 14:09:24:63.805 > > > > UDP message sent (462 bytes): > > > > > > > > > > > > REGISTER sip:my_domain.org SIP/2.0 > > > > To: userA<sip:[EMAIL PROTECTED]> > > > > From: userA<sip:[EMAIL PROTECTED]>;tag=1 > > > > Via: SIP/2.0/UDP 1.2.3.71:20910 > > > > Call-ID: [EMAIL PROTECTED] > > > > Cseq: 1 REGISTER > > > > Contact: <sip:[EMAIL PROTECTED]:20910> > > > > Expires: 100 > > > > Max-Forwards: 70 > > > > Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY, MESSAGE, > > > > SUBSCRIBE, INFO > > > > User-Agent: SIPp userA sip:[EMAIL PROTECTED] > > > > Content-Length: 0 > > > > > > > > > > > > ----------------------------------------------- 2008-01-24 > > > > 14:09:24:69.791 > > > > UDP message received [485] bytes : > > > > > > > > > > > > SIP/2.0 401 Unauthorized > > > > Via: SIP/2.0/UDP 1.2.3.71:20910;received=1.2.3.71 > > > > To: "userA" <sip:[EMAIL PROTECTED]>;tag=a17f6562 > > > > From: "userA" <sip:[EMAIL PROTECTED]>;tag=1 > > > > Call-ID: [EMAIL PROTECTED] > > > > CSeq: 1 REGISTER > > > > WWW-Authenticate: Digest algorithm=MD5, > > > > > > > > nonce="326cc97e75f4477a326cc841e59e1da6f25f821e6311548526df6931a39d0e67", > > > > opaque="326cc97e75f4477a32 > > > > 6cc841e59e1da6f25f821e6311548526df6931a39d0e67", > > > > realm="tel.my_domain.org" > > > > Content-Length: 0 > > > > > > > > > > > > The interesting points are: > > > > > > > > > > > > 1. The timeout is taken from the 401-response (5000ms), not from the > > > > 480-response (10.000ms). > > > > > > > > > > > > 2. In the final screen, the 401-response is marked as timed out - > but > > > > this response has been received. We are waiting for the > 480-response. > > > > > > > > > > > > I'm aware of that the transaction (?) has been finished by the > > > > 401-response. I mean, it is a final response, there cannot be a 2nd > > > > final response. Maybe this is the reason why the timeout of the > > > > following expected final response (in the XML scenario) isn't of > > > > interest. The reason why we made this scenario is to check, which > > > > timeout is taken in case we specify some values using the command > line > > > > option -timeout and/or -recv_timeout. But the given values did not > > > > matter - the timeout always happens after 5sec. > > > > > > > > > > > > Thanks in advance, > > > > > > > > > > > > Frank Ußner > > > > > > > > > > > > > > > > > > > > On Fr, 2008-01-25 at 13:25 +0000, Boulkroune, Olivier (Non-HP:Atos > > > > Origin) wrote: > > > > > When sipp is launched as a server (which is the case here), it > > > > creates a call upon reception of the first message defined in the > > > > scenario. Therefore, if this message is never been received, no call > > > > is created, hence, no call is timeout-ed. > > > > > The -timeout parameter differs from the <recv timeout attribute, > > > > it's global to sipp. > > > > > > > > > > Regards, > > > > > > > > > > Olivier Boulkroune > > > > > > > > > > -----Message d'origine----- > > > > > De : Frederic-Philippe Metz [mailto:[EMAIL PROTECTED] > > > > > Envoyé : vendredi 25 janvier 2008 12:10 > > > > > À : Boulkroune, Olivier (Non-HP:Atos Origin) > > > > > Cc : [email protected] > > > > > Objet : RE: [Sipp-users] Timeout doesn't work fine > > > > > > > > > > Hi, > > > > > > > > > > does that mean that on initial receiving requests the timeout > > > attribute > > > > > on <recv> is ignored ? The attribute is documented under <recv> ? > Is > > > it > > > > > not ignored in other req/resp than the first one in the scenario ? > > > > > > > > > > Cheers > > > > > Frédéric-Philippe Metz > > > > > > > > > > > > > > > On Fr, 2008-01-25 at 10:44 +0000, Boulkroune, Olivier (Non-HP:Atos > > > > > Origin) wrote: > > > > > > Hi, > > > > > > > > > > > > Use the -timeout command line option. It triggers a global > > > > timeout which makes sipp quit if no calls have been received. > > > > > > > > > > > > Regards, > > > > > > > > > > > > Olivier Boulkroune > > > > > > > > > > > > -----Message d'origine----- > > > > > > De : [EMAIL PROTECTED] [mailto:sipp- > > > > [EMAIL PROTECTED] De la part de Frederic-Philippe > > > > Metz > > > > > > Envoyé : vendredi 25 janvier 2008 10:54 > > > > > > À : [email protected] > > > > > > Objet : [Sipp-users] Timeout doesn't work fine > > > > > > > > > > > > Hi all, > > > > > > > > > > > > in the following simple scenario, the timeout doesn't really > work ? > > > > > > > > > > > > Any suggestions ? > > > > > > > > > > > > Cheers, > > > > > > Frédéric > > > > > > > > > > > > > > > > > > <scenario name="Recv-Test-Timeout"> > > > > > > <recv request="INVITE" timeout="2000"> > > > > > > </recv> > > > > > > </scenario> > > > > > > > > > > > > > > > > > > P.S.: Called with > > > > > > ./sipp <IP-Address> -m 1 -i <local-IP> -p <local-Port> -sf > > > <xml-file> > > > > > > > > > > > > and actual svn, but also doesn't work with 2.01 and 3.0 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > ------------------------------------------------------------------------- > > > > > > This SF.net email is sponsored by: Microsoft > > > > > > Defy all challenges. Microsoft(R) Visual Studio 2008. > > > > > > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ > > > > > > _______________________________________________ > > > > > > Sipp-users mailing list > > > > > > [email protected] > > > > > > https://lists.sourceforge.net/lists/listinfo/sipp-users > > > > > -- > > > > > Frédéric-Philippe Metz, Dipl.-Inf. (FH) > > > > > Specialist IP Networks & NGN > > > > > > > > > > currently working for: > > > > > > > > > > IBM Deutschland GmbH > > > > > Global Business Services > > > > > NGN Competence Center > > > > > c/o Deutsche Telekom AG > > > > > Oeserstraße 111 > > > > > 65934 Frankfurt/Main, Germany > > > > > > > > > > Mail : [EMAIL PROTECTED] > > > > > Phone: 069 / 90 55 1 - 223 > > > > > Fax : 069 / 90 55 1 - 200 > > > > > > > > > > > > > > > > > > > > > > > > > > ------------------------------------------------------------------------- > > > > This SF.net email is sponsored by: Microsoft > > > > Defy all challenges. Microsoft(R) Visual Studio 2008. > > > > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ > > > > _______________________________________________ > > > > Sipp-users mailing list > > > > [email protected] > > > > https://lists.sourceforge.net/lists/listinfo/sipp-users > > > > > > ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ Sipp-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/sipp-users
