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

[Stephen McVarnock]

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


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