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
