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
