Klaus, Jonas, cheers for the helpful responses - much appreciated. Thanks again.
Steve. > Hey guys > > Here is what I typically do in a scenario like this: > > SIPp instance no 1 (port x): handles registrations but will register > with NOT with port X but with port Y. > SIPp instance no 2 (port y): handles the "other" traffic, such as > INVITE, MESSAGE whatever. > > The reason for this is that when I do load testing, I cannot go off > and kill my REGISTER SIPp instance plus I don't want to have to deal > with timing issues etc (I haven't noticed that though). Of course, > this assumes there is no NAT between you and the server, which in our > test lab, we dont have (unless we are explicitly testing NAT > scenarios). > > Anyway, just another idea. > > /Jonas > > On Tue, Jan 4, 2011 at 6:14 AM, Klaus Darilion > <[email protected]> wrote: > >> Am 04.01.2011 08:59, schrieb Stephen McVarnock: >> >> >>> 2) I tried to REGISTER the SIPP endpoint in a single xml scenario file >>> with kamailio. This works as per usual. I then killed >>> the SIPP instance and ran a new SIPP script listening on the same port >>> before trying to send the INVITE to it. I expected this to work >>> as the SIPP scenarios (both sending REGISTER and expecting INVITE) >>> listened on the same port. However, the INVITE was not >>> received by the SIPP endpoint. Can anyone think of a reason for this? >>> >> That should work - if you use UDP and the time interval between REGISTER >> and INVITE is small (<30 seconds to avoid NAT/FW issues). >> >> Of course, it also depends if sipp is behind NAT/FW and the Contact used >> by sipp during REGISTER is correct. If there is some kind of NAT/FW then >> you should use fix_nated_register() before save(). >> >> http://www.kamailio.org/docs/modules/3.0.x/modules_k/nathelper.html#id2610858 >> Read carefully and set the mentioned module parameters! >> >> regards >> Klaus >> >> ------------------------------------------------------------------------------ >> Learn how Oracle Real Application Clusters (RAC) One Node allows customers >> to consolidate database storage, standardize their database environment, and, >> should the need arise, upgrade to a full multi-node Oracle RAC database >> without downtime or disruption >> http://p.sf.net/sfu/oracle-sfdevnl >> _______________________________________________ >> Sipp-users mailing list >> [email protected] >> https://lists.sourceforge.net/lists/listinfo/sipp-users >> >> > > ------------------------------------------------------------------------------ > Learn how Oracle Real Application Clusters (RAC) One Node allows customers > to consolidate database storage, standardize their database environment, and, > should the need arise, upgrade to a full multi-node Oracle RAC database > without downtime or disruption > http://p.sf.net/sfu/oracle-sfdevnl > _______________________________________________ > Sipp-users mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/sipp-users > > -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Stephen McVarnock, AePONA Ltd, Interpoint Building, 20-24 York Street, Belfast BT15 1AQ Tel: +44 (0)28 9026 9114 Fax: +44 (0)28 9026 9111 http://www.aepona.com ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ------------------------------------------------------------------------------ Learn how Oracle Real Application Clusters (RAC) One Node allows customers to consolidate database storage, standardize their database environment, and, should the need arise, upgrade to a full multi-node Oracle RAC database without downtime or disruption http://p.sf.net/sfu/oracle-sfdevnl _______________________________________________ Sipp-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/sipp-users
