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

Reply via email to