Michael, My guess is that you are bumping into an open-call limit on the master. You can remove that with -l 0 and it will follow the correct rate for you. If that doesn't work (or if it does) let me know, and I'll try looking at your scenarios and scripts in more detail.
Charles [EMAIL PROTECTED] wrote on 05/30/2008 01:54:25 PM: > I have a fairly complicated set of 3PCC Extended scenario files. I > have a master SIPp instance that talks to a Network SIP Server > (whose only job is to determine which of a number of Premise SIP > Servers to send a call to) and receives a ?302 Moved Permanently?. > The master scenario then determines the appropriate Premise SIP > Server endpoint address from the contact header in the 302 message > and sends the information to the appropriate slave SIPp instance > (Using SendCmd), each of which is connected to a different Premise > Sip Server. When the master sends a message to the slave, it is then > finished its work and can exit, but if it does exit, the slaves die. > To remedy this I tried placing a recvCmd in the master and added a > sendCmd in the slave that will signal the master when the call has completed. > > The problem is, that If we put a SendCmd in the master followed by a > recvCmd so we will be notified when the slave?s call has completed, > the call rate is very low (Essentially, 1 call goes to each slave > and no more calls are generated until those calls have completed). > By removing the recvCmd from the master and replacing it with a > pause of 60 seconds (Call duration is a little less than 60 > seconds), we see the calls processed at the rate we expect (10 calls > / sec default or whatever we put in ?r and ?rp). A pause of only 1 > second causes the same problem as no pause. > > Inserting a pause of appropriate duration does make the problem go > away, but the problem with this is that we don?t know how long the > calls will be processed by the slave. When no agents are available > the calls are queued and could be in the queue for a while. This > makes it difficult to predict how long to make the pause , and we > don?t want to put in something ridiculously large. The question is ? > why does adding a recvCmd in the master and a sendCmd in the slave > cause this behaviour? > > I have attached the shell scripts, the 3PCC Extended config files > and the scenario files. > > They are called in the following order: > > callGeneratorToPremiseSIPServer-1.sh > callGeneratorToPremiseSIPServer-2.sh > callGeneratorToNetworkSIPServer.sh > > thanks for any help you can give, > > > Michael Lynch > > CONFIDENTIALITY NOTICE: This e-mail and any files attached may > contain confidential and proprietary information of Alcatel-Lucent > and/or its affiliated entities. Access by the intended recipient > only is authorized. Any liability arising from any party acting, or > refraining from acting, on any information contained in this e-mail > is hereby excluded. If you are not the intended recipient, please > notify the sender immediately, destroy the original transmission and > its attachments and do not disclose the contents to any other > person, use it for any purpose, or store or copy the information in > any medium. Copyright in this e-mail and any attachments belongs to > Alcatel-Lucent and/or its affiliated entities.[attachment > "callGeneratorToPremiseSIPServer-2.sh" deleted by Charles P > Wright/Watson/IBM] [attachment "slave.cfg" deleted by Charles P > Wright/Watson/IBM] [attachment "slave-1.cfg" deleted by Charles P > Wright/Watson/IBM] [attachment "slave-2.cfg" deleted by Charles P > Wright/Watson/IBM] [attachment "callGeneratorToNetworkSIPServer.sh" > deleted by Charles P Wright/Watson/IBM] [attachment > "callGeneratorToNetworkSIPServer.xml" deleted by Charles P > Wright/Watson/IBM] [attachment "callGeneratorToPremiseSIPServer.xml" > deleted by Charles P Wright/Watson/IBM] [attachment > "callGeneratorToPremiseSIPServer-1.sh" deleted by Charles P > Wright/Watson/IBM] > ------------------------------------------------------------------------- > This SF.net email is sponsored by: Microsoft > Defy all challenges. Microsoft(R) Visual Studio 2008. > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ > _______________________________________________ > Sipp-users mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/sipp-users ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ Sipp-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/sipp-users
