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 <zendel.fernan...@gmail.com > wrote: > 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* > ---------------- > > See the example URL for for similar implementations. > > > > Regds > > > > > On Thu, Aug 8, 2013 at 2:03 PM, Paul Belanger < > paul.belan...@polybeacon.com> wrote: > >> On 13-08-07 08:42 PM, zendel fernandez wrote: >> >>> 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<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 ? >>> >>> 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. >> >> -- >> Paul Belanger | PolyBeacon, Inc. >> Jabber: paul.belan...@polybeacon.com | IRC: pabelanger (Freenode) >> Github: https://github.com/pabelanger | Twitter: >> https://twitter.com/pabelanger >> >> -- >> ______________________________**______________________________**_________ >> -- Bandwidth and Colocation Provided by http://www.api-digital.com -- >> New to Asterisk? Join us for a live introductory webinar every Thurs: >> http://www.asterisk.org/hello >> >> asterisk-users mailing list >> To UNSUBSCRIBE or update options visit: >> >> http://lists.digium.com/**mailman/listinfo/asterisk-**users<http://lists.digium.com/mailman/listinfo/asterisk-users> >> > >
-- _____________________________________________________________________ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- New to Asterisk? Join us for a live introductory webinar every Thurs: http://www.asterisk.org/hello asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users