On 1/3/08, Peter Higginson <[EMAIL PROTECTED]> wrote: > > optional="global" should find the message at any earlier point in the > script. So you could use that and move it completeley away from the INFO > recv (and the preceding send). You then would not need a timeout on it.
Using this I can finally obtain the behaviour I need. Thank you much to all who answered ! Regards, K.L. > > Peter Higginson > Newport Networks Ltd, > http://www.newport-networks.com/ > > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of K L > Sent: 03 January 2008 13:59 > To: Boulkroune, Olivier (Non-HP:Atos Origin) > Cc: [email protected] > Subject: Re: [Sipp-users] Strange behaviour on recv+optional+ontimeout > > On 1/3/08, Boulkroune, Olivier (Non-HP:Atos Origin) > <[EMAIL PROTECTED]> wrote: > > Hi, > > > > Why do you need an ontimeout attribute ? Can't you just put > > > > <label id="1" /> > > <recv request="BYE" optional="true" next="4"/> > > > > <label id="2" /> > > <recv request="INFO" optional="false" timeout="10000" ontimeout="3" > > /> > > > > I can't do that because I want the timeout of 25s to be honored if no BYE is > received. My scenario must check the timing of the messages, not only their > sequence. > > > ? > > > > If this BYE can also be received after the INFO message, an > optional="global" element migh be used to make the BYE taken into account > and jump to label 4. > > > > If I put optional="global", does this mean that the BYE may be received at > any time during the scenario ? I will try that and replace the timeout in > the BYE by a pause. > > > Or do I miss something ? > > > > Regards, > > > > Olivier Boulkroune > > > > Regards, > K.L. > > > -----Message d'origine----- > > De : [EMAIL PROTECTED] > > [mailto:[EMAIL PROTECTED] De la part de K L > > Envoyé : mercredi 2 janvier 2008 17:23 À : Charles P Wright Cc : > > [EMAIL PROTECTED]; > > [email protected] Objet : Re: [Sipp-users] Strange > > behaviour on recv+optional+ontimeout > > > > On 1/2/08, Charles P Wright <[EMAIL PROTECTED]> wrote: > > > K L, > > > > > > If you jump to the end of the call SIPp marks it as failed > > > automatically (which I think is probably not the best possible > > > behavior), but you can easily get around it by doing something like: > > > > In my case, I don't jump to the end of the scenario: > > > > - If a BYE is received, I jump to the "next" label (4) to send a 200 OK. > > - If no BYE is received, I jump to the "ontimeout" label (2), to wait > > for another request (non-optional). > > > > So, in both cases, there is an action made, and I do not jump to the > > end of the scenario. > > > > > > > > <recv request="BYE" timeout="25000" ontimeout="2" next="4" /> > > > > > > ... > > > > > > <label id="2" /> > > > <!-- just so we have a scenario element after label 2 --> <nop /> > > > <!-- end of scenario --> > > > > > > Charles > > > > > > > Regards, > > K.L. > > > > > [EMAIL PROTECTED] wrote on 12/31/2007 09:51:39 > AM: > > > > > > > Hello, > > > > > > > > In a (UAC) scenario, I have the following line, to allow the > > > > remote UA to send a BYE during the call (after the dialog is > > > > established): > > > > > > > > <recv request="BYE" optional="true" timeout="25000" ontimeout="2" > > > next="4" /> > > > > > > > > Whether a BYE is received or not, I'd like the call to be > > > > considered as successful. > > > > If no BYE request is received from the remote UA, the call > > > > proceeds > > > normally. > > > > The problem is that the call is considered as failed by SIPp > > > > ("receive timeout on message 10, jumping to label 2"). > > > > > > > > Since the recv is marked as "optional", it seems strange to me > > > > that SIPp considers the jump to label 2 as an error. Is there an > > > > option to change > > > this > > > > behaviour ? > > > > > > > > Regards, > > > > K.L. > > > > > > > > > > > -------------------------------------------------------------------- > > > ----- > > > > This SF.net email is sponsored by: Microsoft Defy all challenges. > > > > Microsoft(R) Visual Studio 2005. > > > > 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 2005. > > 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 2005. > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ > _______________________________________________ > Sipp-users mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/sipp-users > > > > --------------------------------------------------------------------------------------------- > This e-mail may contain confidential and/or privileged information. > If you are not the intended recipient (or have received this e-mail in error) > please > notify the sender immediately and delete this e-mail. Any unauthorized > copying, > disclosure or distribution of the contents in this e-mail is strictly > forbidden. > --------------------------------------------------------------------------------------------- > Newport Networks Limited is registered in England. Registration number > 4067591. > Registered office: 6 St. Andrew Street, London EC4A 3LX > --------------------------------------------------------------------------------------------- > > ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ Sipp-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/sipp-users
