Queue Member Ackcall – Cpuspikes

Home » Asterisk Users » Queue Member Ackcall – Cpuspikes
Asterisk Users 3 Comments

hi!,

Asterisk Version:1.6.1.20
OS: CentOS release 5.3 (Final)
uname: 2.6.18-128.el5PAE #1 SMP Wed Jan 21 11:19:46 EST 2009 i686 i686 i386
GNU/Linux Application: Queue Specific Details: Obtain Acknowledgement from queue member before bridging the caller. Language: AEL
Similar Example:http://www.voip-info.org/wiki/view/Asterisk+tips+Queue+Member+ackcall

Scenario:
1. User calls in a General Number

2. Call is queued in Queue Application

3. Queue calls a Local/xxxx@members channel

4. At members context:
Dial The real member(called party) channel with a U(GOSUB X) routine
4.1 The “called party” answers, & is led to the GOSUB routine X:
Here the prompt is given to the called party to acknowledge the incoming call
[ depending on the out put, this will return appropriate GOSUB result ]
4.2 Based on the GOSUB result, the Dial proceeds

5. The Queue proceeds based on the result taken at 4.2 above. i.e. Take it as a success & build the bridge between the caller & member Whether to DIAL the next member

The Question: All goes well & the dial-plan works. If between step 4.1 &
4.2, the caller hangs up asterisk gives CPU spikes. Symptom: ASTERISK CLI gets stuck until step 4.2 returns.

Console Error: app_dial.c: Could not stop autoservice on calling channel
[ Somehow get the feeling that this is not the real error]

What could be the reason for CPU SPIKES. How to avoid this ?

Regds.

3 thoughts on - Queue Member Ackcall – Cpuspikes

  • What are you doing in your GOSUB X routine, you are likely blocking the thread in Asterisk, which is causing your autoservice errors (and yes, they are real errors) which increases the CPU on asterisk.

  • hi!

    GOSUB X
    * Presents Background message to the called party
    * check if there’s any inputs from the user ( Press 1 etc )
    * exit if called party provide input *or not*
    ————–

  • And further,

    No matter what contains in the GOSUB (In this case relatively simple stuff), when the A party hangup, the queue should signal the B
    Channel(Member) to hangup. [ Which should tear down member LEG immediately ]

    The problem here is Queue is not able to hangup the member leg even though the original caller has disappeared [Just because B channels is in a GOSUB
    ].

    .

    On Thu, Aug 8, 2013 at 4:41 PM, zendel fernandez