I tried to use the scenario described in the link below,
unfortunately my sipp crashes with segmentation fault. Have
raised an issue in GitHub
https://sourceforge.net/p/sipp/mailman/message/34707334/
Any other ways I can achieve what I initially posted...
On Mon, Oct 5, 2020 at 2:23 PM sshark wsk <sshark...@gmail.com
<mailto:sshark...@gmail.com>> wrote:
I have the below. I guess for the called party, as I am
finishing the thread for registration adn then wait for
INVITE in the same IP/port it seems to work. Maybe it's not a
good idea ?
Do you think the 3PCC scenario is the only way it will work
for my requirement ?
_Server1 script_
bindIP=10.10.10.1
port=5060
./sipp $proxyIP -i $bindIP:$port -nd -t t1 -l 2 -m 1 -sf
./register_and_call.xml -inf ./A_user.csv -trace_msg
_Server2 script_
bindIP=10.10.10.2
port=5061
./sipp $proxyIP -i $bindIP:$port -nd -t t1 -l 2 -m 1 -sf
./reg.xml -inf ./B_user_register.csv -trace_msg
./sipp $proxyIP -i $bindIP:$port -nd -t t1 -l 2 -m 1 -sf
./receive.xml -inf ./B_user_answer.csv -trace_msg
I also saw some other posting where you can run UAC & UAS
with one instance of the sipp. Does that work ?
https://github.com/SIPp/sipp/issues/362
On Mon, Oct 5, 2020 at 1:26 AM Šindelka Pavel
<sinde...@ttc.cz <mailto:sinde...@ttc.cz>> wrote:
> my plan for the called user is to keep different
> scenarios for register and process invites.
But that's only possible if the tested device is fine
with the REGISTER
coming from a different socket than the one which is
indicated in the
Contact uri, as is the case with vanilla SIP. In real
life environments,
which I suppose you are going to test, the SBC stores the
actual socket
from which the REGISTER has arrived, and sends the INVITE
to that stored
socket regardless what was written in the Contact uri in
the REGISTER.
As you want the calls to overlap, the scenario expecting
the INVITEs
(and later on receiving or sending the BYEs) must be running
continuously, so you cannot simultaneously send the
REGISTERs from the
same socket.
> I am struggling with the setup to continue to run
called user to
> continuously process invites. Should I be just using
labels to
> continue the loop in the "process invites" scenario ?
This sounds to me as if you haven't understood the
relationship between
threads and Call-IDs. At the beginning, the scenario
receives an initial
INVITE with some Call-ID yet unknown to it, so it spawns
a new thread
for that call, answers the INVITE with a 200, then
receives or sends a
BYE and responds it/gets it responded with a 200, and all
that time the
Call-ID stays attached to the thread. If there are no
other messages to
send or receive left in the scenario, the thread will end
after some
guard timer expires (which is there to handle eventual
retransmissions
of the BYE or the 200 to it if they arrive) and SIPp
stops recognizing
that Call-ID, but if you jump to the beginning of the
scenario, the
thread will expect another INVITE with the same Call-ID -
which will
never arrive (or at least should never arrive).
So you don't need to do anything special in order that a
scenario was
ready for a new call. It just sits there listening at its
socket, and if
an INVITE with a yet unknown Call-ID arrives, it handles
it in a freshly
spawn dedicated thread. If several INVITEs come "at once"
with an
individual Call-ID each, several threads get spawned "at
once".
P.
Dne 04.10.2020 v 14:27 sshark wsk napsal(a):
> Hi Pavel,
>
> Thanks, yes I did go through that post and various
other posts
> describing the challenges of running UAC & UAS for
called party..
> As I mentioned, my plan for the called user is to keep
different
> scenarios for register and process invites.
>
> I am struggling with the setup to continue to run
called user to
> continuously process invites. Should I be just using
labels to
> continue the loop in the "process invites" scenario ?
>
> //sshark
>
> On Sat, Oct 3, 2020 at 6:19 PM Šindelka Pavel
<sinde...@ttc.cz <mailto:sinde...@ttc.cz>> wrote:
>> Hi sshark,
>>
>> could you please read
https://sourceforge.net/p/sipp/mailman/message/34707334/
first if you haven't yet?
>>
>> I think I've put pretty much everything in there on
how to create "amphibious" scenarios behaving as both UAC
and UAS, which is what you need in order to create a
scenario which will register and keep updating the
registration (as a UAC) and answer incoming calls (as a
UAS) while it stays bound to the same local UDP socket.
The need to stay bound to the same socket explains why I
deem all the timing to be done using SIPp itself to be a
better way than using bash scripts to spawn execution of
the scenarios. It's true, however, that on the calling
side you could spawn a registration, outgoing call, and
unregistration as three separate scenarios binding to the
same local port by shell script, but then you'd have to
use one socket per user.
>>
>> I didn't detail there the reasons why a Call-ID of a
REGISTER must be different from the one of the INVITE,
but normal SIP stacks should ignore or reject an INVITE
with the same Call-ID like one in a previously received
REGISTER, at least if it came soon enough after that
REGISTER.
>>
>> So as you don't insist on the unregistrations at the
called side (from the point of view of traffic volume,
registration updates will generate 1/2 of the traffic
volume as compared to un-registrations and
re-registrations with the same periodicity), the A and B
scenarios (or rather scenario pairs) can be completely
independent. Plus in the wild, an active un-registration
is a rare beast.
>>
>> There's just one point to the periodicity of the
registration updates, some registrars/SBCs have not only
maximum registration time but also a minimum one, and if
you attempt to register for a shorter time, they respond
with "423 interval too brief", so even if you'll be
actually updating the registration every minute, you have
to indicate an Expires value which will satisfy the SBC
and/or registrar.
>>
>> So in my approach, the B scenario would optionally
accept and respond INVITEs (and possibly OPTIONS
depending on the behaiour of the system being tested) by
a corresponding branch, and mandatorily accept commands
from the timer instance and spawn another branch which
would periodically register. Eventually, that branch
could accept a termination command from the timer
instance if you want the scenario group to terminate
autonomously after a predefined number of cycles or
amount of time (I've never tried the -m command line
option with a UAS scenario, maybe it works too).
>>
>> The A scenario would accept trigger commands from its
own timer scenario, where a single call in the timer
scenario would use two distinct Call-IDs in the commands
it would send to the executive scenario a few seconds
apart: the first one would be made up and would trigger
the registration, the second one would be the native one
of the timer scenario and would trigger the outgoing
call. The random duration of the outgoing call would be
determined by the executive scenario, which would send a
command to the timer one as a notification that the call
has ended; in response to that, the timer would send back
a command with the made-up call ID to trigger the
unregistration. This way of synchronizing two threads
within the same scenario is the simplest one I could find
throughout the years.
>>
>> The overlapping would be provided by the -l 2 command
line option as I've suggested earlier (third call cannot
start until the first one ends).
>>
>> P.
>>
>> Dne 03.10.2020 v 6:11 sshark wsk napsal(a):
>>
>> Thanks for the email, The main goal for me is to keep
some constant
>> traffic on the SIP servers. I thought of having
>> registration/deregistration flows as they do invoke
different
>> functions/procedures within the SIP server. If it
introduces too much
>> complexity, then I am happy with doing re-registration
rather than
>> de-register/register again...
>>
>> How can I approach in doing this, can sipp orchestrate
this or better
>> use shell script to do a loop and use sipp ?
>>
>> Thanks for your help..
>>
>> On Sat, Oct 3, 2020 at 4:07 AM Šindelka Pavel
<sinde...@ttc.cz <mailto:sinde...@ttc.cz>> wrote:
>>
>> Okay, the diagram shows clearly that the calls can and
should overlap.
>>
>> Is it an absolute must that the called side was
de-registering and
>> re-registering again for every call, or may it
register in the beginning
>> and keep renewing the registration periodically, and
just accept
>> incoming calls? If the unregistration of the called
side is not
>> mandatory, this will remove the need for
synchronization between the A
>> side script and the B side script.
>>
>> P.
>>
>> Dne 30.09.2020 v 14:35 sshark wsk napsal(a):
>>
>> I have below setup available with me
>> Shell Script1: Handles A party
>> Scenario 1 - A user to register and send INVITE and
handle subsequent
>> messages (180, 200OK, ACK) and then deregister user
>>
>> Shell Script2: Handles B party
>> Scenario 2 - B user to register
>> Scenario 3 - B user to accept INVITE and handle
appropriate messages
>> (180, 200OK, ACK)
>> Scenario 4 - B user to de-register
>>
>> Have drafted a sequence diagram on what I had in mind.
I hope it
>> explains what I have in mind..
>>
>>
>>
>> On Wed, Sep 30, 2020 at 2:37 AM Šindelka Pavel
<sinde...@ttc.cz <mailto:sinde...@ttc.cz>> wrote:
>>
>> Do you want a single scenario to act as both A and B
subscribers or you plan to use two scenarios? The thing
is that if you want each user to unregister after the
call, you need to have some synchronization between the A
and B side even if each runs as a separate scenario on a
different machine, otherwise you'll find A knocking on a
closed door at B sooner or later.
>>
>> You also state contradictory requirements - if you
want at least one call "on air" at any given instant of
time, the calls must be overlapping, whereas
unregistering An,Bn after a call and then registering
An+1,Bn+1 creates a gap between the calls. So choose
which one of these two requirements is more important.
>>
>> My approach would be to use a timer scenario, sending
sync messages to both the A and B scenarios, with
Call-IDs in the sync messages generated from
[call_number] so that the sync message triggering the
REGISTER at A and the one triggering the INVITE at A
would be sent by the same call at the timer scenario but
seen as two independent calls at the A scenario. To
choose the right row in the csv file, I'd compute the row
ID in the timing scenario and deliver it from there as a
value of some P-user-index header - this way, all the
calculations (call number modulo 5) would be done in the
timer scenario and the A and B scenarios would just use
the value extracted from that header in the
synchronization messages. So you would not need to start
sipp in loops, you'd just specify the total number of
calls and number of calls per unit of time, and the
modulo 5 would do the rest of the job.
>>
>> I remember I was not able to make the 3PCC extended
work some years ago, so you may have tough time making
three scenarios (timer, A, B) work, but maybe it's not an
issue any more, or it even never was and it was just some
mistake I could not find in my setup.
>>
>> -l 2 option on the command line should make sure that
not more than two trigger calls will be active
simultaneously, so the third call should not start before
the first one finishes.
>>
>> Pavel
>>
>> Dne 29.09.2020 v 14:07 sshark wsk napsal(a):
>>
>> Continuation to below thread, I have some additional
questions
>> https://sourceforge.net/p/sipp/mailman/message/35176307/
>>
>> I would like to know if anyone has some sample
scenario files for
>> 1. Have bunch of users for A (5) & B (5)
>> 2. Register B1 party and listen for INVITEs
>> 3. Register A1 party and setup call towards A party
>> 4. Keep the call predefined period/can be random (~10s)
>> 5. Terminate the call
>> 6. De-register A1 & B1
>> 7. Continue to the next set of users - A2/B2, A3/B3,
A4/B4, A5/B5
>> 8. Once list is exhausted, start from A1/B1
>>
>> I am able to create the scenario file
(Register/call/answer), however
>> would like to get some hints on how to do the below
>> - How SIPp can be scheduled to run through a loop
>> - Our goal is to have at least 1 call through the
network at a given
>> point of time to simulate background testing
>>
>> Thank You in advance for any inputs/feedback
>>
>>
>> _______________________________________________
>> Sipp-users mailing list
>> Sipp-users@lists.sourceforge.net
<mailto:Sipp-users@lists.sourceforge.net>
>> https://lists.sourceforge.net/lists/listinfo/sipp-users
>>
>> _______________________________________________
>> Sipp-users mailing list
>> Sipp-users@lists.sourceforge.net
<mailto:Sipp-users@lists.sourceforge.net>
>> https://lists.sourceforge.net/lists/listinfo/sipp-users
