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.
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
