[asterisk-dev] Question on the SIPPTest class in the testsuite

nitesh bansal nitesh.bansal at gmail.com
Fri Oct 5 07:29:02 CDT 2012


Thanks for the suggestions. I'll be soon migrating to 1.11 and what i
understand is that in 1.11, it won't be a problem, so that solves my
problem;

On Fri, Oct 5, 2012 at 2:13 PM, Matthew Jordan <mjordan at digium.com> wrote:

> On 10/05/2012 03:11 AM, nitesh bansal wrote:
> >
> > I am using the Asterisk Version 1.4.
> >
> > As per the logs, it looks that asterisk has not loaded the dialplan yet,
> > the problem can be reproduced on Asterisk 1.4 by putting a bogus address
> > in res_mysql.conf, which will result in asterisk trying to connect to
> > this bogus address and it will increase the loading time of asterisk.
> >
> > Remark;
> > "I just checked that core waitfully booted" does not exist on 1.4, so
> > probably i am likely to have this problem on 1.4"
> >
>
> Yikes.  While the Asterisk Test Suite has been run against 1.4, it has
> been quite awhile since that occurred, and a lot has changed in it since
> that was anything close to a regular occurrence.  There are certainly
> mechanisms in Asterisk 1.8+ that the Test Suite uses to orchestrate
> tests that won't be available to you.
>
> Is there a reason why you need res_mysql or res_mysql.conf?
>
> If you do, you may still be able to do this by writing your own test
> derived from Test Case.  You could make a 'dummy' extension in your
> dialplan that simply answers a call.  You can test for whether or not
> the dialplan is loaded by originating a local call into that extension
> and - if it succeeds - start your actual test.  This is a bit hackish,
> and there are other ways you may approach doing this (such as adding an
> AMI event when the dialplan is fully loaded), but most other ways I can
> think of require modifying Asterisk itself.
>
> Something like this:
>
> extensions.conf:
>
> [default]
>
> exten => dummy,1,NoOp()
>        same => n,Answer()
>        same => n,Hangup()
>
> run-test.py:
>
> def ami_connect(self, ami):
>    super(TestName, self).ami_connect(ami)
>
>
>    self.__check_connected(ami)
>
>
> def self.__check_connected(self):
>
>    def __originate_callback(self, result):
>        ''' Originate occurred successfully, call the actual test '''
>
>        self.__start_sipp_test()
>        return result
>
>    def __originate_errback(self, result):
>        ''' Originate failed, call again in 2 seconds (or some other
> backoff time '''
>        # The reactor timeout will eventually kill this and prevent
>        # it from looping endlessly, but you may want a more elegant
>        # way of eventually deciding that you aren't going to connect
>        reactor.callLater(2, self.__check_connected)
>
>     # If you have multiple Asterisk instances this will only test
>     # against the first.  You could do something here
>     df = self.ami[0].originate(channel='Local/dummy at default',
>                                application='Echo')
>
>     df.addCallbacks(self.__originate_callback, self.__originate_errback)
>
>
> def self.__start_sipp_test(self):
>
>     # Start your SIPp test here using SIPpScenario
>
>
>
> --
> Matthew Jordan
> Digium, Inc. | Engineering Manager
> 445 Jan Davis Drive NW - Huntsville, AL 35806 - USA
> Check us out at: http://digium.com & http://asterisk.org
>
>
>
> --
> _____________________________________________________________________
> -- Bandwidth and Colocation Provided by http://www.api-digital.com --
>
> asterisk-dev mailing list
> To UNSUBSCRIBE or update options visit:
>    http://lists.digium.com/mailman/listinfo/asterisk-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-dev/attachments/20121005/bf70b9b0/attachment.htm>


More information about the asterisk-dev mailing list