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
