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
