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> 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> 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
https://lists.sourceforge.net/lists/listinfo/sipp-users
_______________________________________________
Sipp-users mailing list
Sipp-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sipp-users
_______________________________________________
Sipp-users mailing list
Sipp-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sipp-users
