I changed to UDP and verified and still the same - SIPp crashes in the called party when it receives the recvCmd. I guess the scenario you described is not be possible based on what is stated in issue #493
On Mon, Nov 2, 2020 at 1:45 AM Šindelka Pavel <sinde...@ttc.cz> wrote: > The missing part of the puzzle was that you use TCP. So there are two > issues, one related to SIPp and another one related to real world > deployment: > > - with TCP, the difference between UAC mode and UAS mode begins as low > as in whether to bind to port 5060 for listening as UAS, or whether to bind > to an ephemeral port for sending as UAC. I am not sure how this is > internally handled in SIPp. > - in real SIP deployment, the devices are rarely on public IPs, so the > mode where each peer establishes its own TCP session (or even more sessions > in sequence) towards the other peer's port 5060 to send its requests and > receive responses to them is not practically usable on the call path > between CPE and the exchange (or SBC). So if a CPE needs to use TCP to talk > to the exchange (e.g. because TLS is used), the CPE needs to establish a > TCP session as a client, in order to deliver the REGISTER, but that session > then stays open "forever" (and prolonged by the the re-REGISTERs), and is > reused not only for requests sent by the CPE (like outgoing INVITEs), but > also for requests sent by the exchange (incoming INVITEs from the CPE > perspective). I'm afraid I cannot imagine how to imitate this behaviour > using SIPp without modifying the code, which is way above my capabilities. > > P. > > > Dne 01.11.2020 v 1:20 sshark wsk napsal(a): > > Here are the scenario files, input files & scripts. I will try and test > with an older version of SIPp. I have to build it for my environment > > Thanks > > On Sun, Nov 1, 2020 at 7:31 AM Šindelka Pavel <sinde...@ttc.cz> wrote: > >> Until the bug gets fixed, can you try an older version of SIPp? Or, can >> you send me your scenarios for checking on my 3.6.0? >> >> P. >> Dne 28.10.2020 v 10:23 sshark wsk napsal(a): >> >> 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
