[SR-Users] [Sipp-users] Use of SIPP along with kamailio - REGISTER followed by INVITE not working

[Jonas Borjesson]

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
<klaus.mailinglists at pernau.at> 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
> Sipp-users at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/sipp-users
>