I tried to use the scenario described in the link below, unfortunately my sipp crashes with segmentation fault. Have raised an issue in GitHub https://sourceforge.net/p/sipp/mailman/message/34707334/
Any other ways I can achieve what I initially posted... On Mon, Oct 5, 2020 at 2:23 PM sshark wsk <sshark...@gmail.com> wrote: > 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
