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
