Scott, I actually have an out-of-tree patch that allows names for labels (e.g., "start" and "end") and variables, which will warn if there is an invalid name (at scenario load time). The variable patch will also complain if there is an unsed variable (though needs some follow on patches that conver various things to static sending messages).
Olivier, perhaps it is time to fork the 3.0.0 branch as a release candidate, and resume development in the trunk? I have several other patches that I have been holding back for a couple of months in anticipation of 3.0. Charles [EMAIL PROTECTED] wrote on 11/20/2007 02:49:22 PM: > Actually, I had <lablel id="5"/> (and if you don't have an id string in > the label, the code core dumps; scenario.cpp line 566 assumes that the > id string was found instead of checking for a null pointer). But you > are correct that I was branching where I didn't expect (because the > number was wrong). > > Is this really the desired behavior? Seems like the contents of > labelArray could be initialized to -1 and call.cpp could check for that > value, and alert the user that the scenario file is wrong. Then people > like me who continually make stupid mistakes wouldn't be so confused > about what's going on. > > If there's no reason not to do that, I can generate a patch. > > -Scott > > On Tue, 2007-11-20 at 13:44, Charles P Wright wrote: > > Scott, > > > > Change your label to <label id="5" />. The situation you are seeing is > > that the label is not getting found, so the call ends and a new one > > replaces it. > > > > Charles > > > > [EMAIL PROTECTED] wrote on 11/20/2007 01:39:14 PM: > > > > > I need to construct a scenario where a sipp uac sends a SUBSCRIBE > > > message to resubscribe to an exisiting subscription before the > > > expiration. I tried something like > > > > > > <label next="5"> > > > <send > > > ...subscribe data with expire: 3600 seconds/> > > > <recv OK> > > > <recv NOTIFY> > > > <send OK> > > > <pause 1800 seconds next="5"> > > > > > > But when the scenario loops, the call_id is incremented (and the branch > > > and tags are changed), so the presence server thinks it's a new > > > subscription. > > > > > > Is there a way to get the subscribe re-sent without changes? I need to > > > test TCP, so I can't use the retrans part of the send command (not even > > > sure if I could somehow fake it with that, but since it's TCP, I didn't > > > look into it). > > > > > > -Scott > > > > > > > > > > > ------------------------------------------------------------------------- > > > 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 > > >
namedvariables.diff
Description: Binary data
namedlabels.diff
Description: Binary data
------------------------------------------------------------------------- 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
