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
