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
