I have the below. I guess for the called party, as I am finishing the thread for registration adn then wait for INVITE in the same IP/port it seems to work. Maybe it's not a good idea ? Do you think the 3PCC scenario is the only way it will work for my requirement ?
*Server1 script* bindIP=10.10.10.1 port=5060 ./sipp $proxyIP -i $bindIP:$port -nd -t t1 -l 2 -m 1 -sf ./register_and_call.xml -inf ./A_user.csv -trace_msg *Server2 script* bindIP=10.10.10.2 port=5061 ./sipp $proxyIP -i $bindIP:$port -nd -t t1 -l 2 -m 1 -sf ./reg.xml -inf ./B_user_register.csv -trace_msg ./sipp $proxyIP -i $bindIP:$port -nd -t t1 -l 2 -m 1 -sf ./receive.xml -inf ./B_user_answer.csv -trace_msg I also saw some other posting where you can run UAC & UAS with one instance of the sipp. Does that work ? https://github.com/SIPp/sipp/issues/362 On Mon, Oct 5, 2020 at 1:26 AM Šindelka Pavel <sinde...@ttc.cz> wrote: > > my plan for the called user is to keep different > > scenarios for register and process invites. > But that's only possible if the tested device is fine with the REGISTER > coming from a different socket than the one which is indicated in the > Contact uri, as is the case with vanilla SIP. In real life environments, > which I suppose you are going to test, the SBC stores the actual socket > from which the REGISTER has arrived, and sends the INVITE to that stored > socket regardless what was written in the Contact uri in the REGISTER. > > As you want the calls to overlap, the scenario expecting the INVITEs > (and later on receiving or sending the BYEs) must be running > continuously, so you cannot simultaneously send the REGISTERs from the > same socket. > > > 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 ? > This sounds to me as if you haven't understood the relationship between > threads and Call-IDs. At the beginning, the scenario receives an initial > INVITE with some Call-ID yet unknown to it, so it spawns a new thread > for that call, answers the INVITE with a 200, then receives or sends a > BYE and responds it/gets it responded with a 200, and all that time the > Call-ID stays attached to the thread. If there are no other messages to > send or receive left in the scenario, the thread will end after some > guard timer expires (which is there to handle eventual retransmissions > of the BYE or the 200 to it if they arrive) and SIPp stops recognizing > that Call-ID, but if you jump to the beginning of the scenario, the > thread will expect another INVITE with the same Call-ID - which will > never arrive (or at least should never arrive). > > So you don't need to do anything special in order that a scenario was > ready for a new call. It just sits there listening at its socket, and if > an INVITE with a yet unknown Call-ID arrives, it handles it in a freshly > spawn dedicated thread. If several INVITEs come "at once" with an > individual Call-ID each, several threads get spawned "at once". > > P. > > Dne 04.10.2020 v 14:27 sshark wsk napsal(a): > > 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
