I'm not sure this is as easy to do because how would SIPp know which call to use for handling INVITE messages if it isn't based on the CallID? Sure it could be done but it would completely change the simple call mapping logic in SIPp (unknown CallID start a new call at first scenario step; existing CallID use same call as previous messages). Also it feels very counterintuitive to me. A scenario consists in a series of steps to execute for a call or session. Register and a call are clearly two distinct scenarios and should not be mangled into a single one. Well ... that's just my point of view and I'm sure you could find a way to explain your suggestion makes more sense...
Anyway, you might be interested in the 'ims_bench' code branch that we at Intel will populate in the coming couple of weeks (after a very long delay mainly due to legal procedures) and which provides an implementation of the ETSI IMS/NGN Performance Benchmark specification. This branch will have support for multiple scenarios in a single SIPp. It will require some more configuration than the original SIP but it should allow you to have a register and an invite scenario, with the invite one only done for the users that have previously registered. The implementation also brings quite a bit of randomness as that is part of the benchmark. Depending on your needs that might be just what you want or you might be able to limit that. The new branch will come with extensive documentation as it significantly differs from the current SIPp. Stay tuned... -David -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Clemix Sent: 28 September 2007 08:20 To: Charles P Wright Cc: sipp-users Subject: Re: [Sipp-users] REGISTER before recv INVITE in one XML scenario Charles P Wright schrieb: > [EMAIL PROTECTED] wrote on 09/27/2007 08:45:12 AM: > >> Registration works fine. And the INVITE package will send with the right >> > > >> Port to the UAS. >> But Sipp discard this massage because the CallID dosn't match >> (reference.html#Unexpected+messages) >> but i Need to Reset the callID because Register and "recv" always will >> have different one! Is there a solution. I didn't find any in >> doc or google. If i split the XML scenario file from sipp1 in to two >> parts, first to Register and the >> second to receive it works but this is a bad solution i think. Someone >> knows a solution? >> > Splitting the register and UAS is actually the preferred solution. > > Charles hm, in my test environment is it possible but i like to have a little command like <resetCallID/> to do this. It can not be such complicated to implement something like that because the reset is done every new Call or? clemix ------------------------------------------------------------------------ - 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 --------------------------------------------------------------------- Intel Corporation NV/SA Rond point Schuman 6, B-1040 Brussels RPM (Bruxelles) 0415.497.718. Citibank, Brussels, account 570/1031255/09 This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies. ------------------------------------------------------------------------- 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
