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> 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> 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
