>Are you saying that this worked in earlier versions but you started to >get the delay when you updated to 11.21.0? Or just that you happened to >be using 11.21.0 the first time you tried this scenario?I should have said "first time" trying this. Any thoughts? Jerry -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.digium.com/pipermail/asterisk-users/attachments/20160121/864b157d/attachment.html>
In article <CABr8-B5HQBy1vU2i=6iV5TbC0-yNG0HxM8c-M2O1XC7YDMvE-A at mail.gmail.com>, Jerry Geis <geisj at pagestation.com> wrote:> > >Are you saying that this worked in earlier versions but you started to > >get the delay when you updated to 11.21.0? Or just that you happened to > >be using 11.21.0 the first time you tried this scenario? > > I should have said "first time" trying this. > > Any thoughts?Not really. Very little info to go on so far. You need to give us more detail of what you are doing with AGI and AMI. Cheers Tony -- Tony Mountifield Work: tony at softins.co.uk - http://www.softins.co.uk Play: tony at mountifield.org - http://tony.mountifield.org
>Not really. Very little info to go on so far. You need to give us >more detail of what you are doing with AGI and AMI.Sorry - let me try again... I am basically doing the following: 1) calling a phone SIP/401 upon answer run an AGI for voice prompts etc... to select AUDIO groups 2) when done setup to return to the dialplan - exit AGI 3) issue AGI that calls those groups selected (SIP/430 & SIP/431) at the moment to bring into a conference. 4) Wait 10 seconds 5) jump SIP/401 into conference 6) speak live to endpoints. However my issue is such that step 3 above "seems" to block until after step 5. My Manager AMI connection reports success in step 3: 21-Jan-16 01:02 pm asterisk_pa_list() manager_str Action: Originate[CR ][LF ]Async: Yes[CR ][LF ]Channel: SIP/430[CR ][LF ] (truncated) 21-Jan-16 01:02 pm asterisk_pa_list() manager_str return Response: Success[CR ][LF ]Message: Originate successfully queued[CR ][LF ][CR ][LF ] I was expecting the jump into conference from step 3 to go ahead and do the request - not wait till after step 5. Does this help? What am I not doing right so the calls in step 3 happen WAY before the 10 seconds is complete? Jerry -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.digium.com/pipermail/asterisk-users/attachments/20160121/93600b01/attachment.html>
In article <CABr8-B5ejk4Q5tfU4hYGpgq=0pp=rXUKz+fCUesEeNQimmKgxw at mail.gmail.com>, Jerry Geis <geisj at pagestation.com> wrote:> > >Not really. Very little info to go on so far. You need to give us > >more detail of what you are doing with AGI and AMI. > > Sorry - let me try again... > > > I am basically doing the following: > 1) calling a phone SIP/401 upon answer run an AGI for voice prompts etc... > to select AUDIO groups > 2) when done setup to return to the dialplan - exit AGI > 3) issue AGI that calls those groups selected (SIP/430 & SIP/431) at the > moment to bring into a conference. > 4) Wait 10 seconds > 5) jump SIP/401 into conference > 6) speak live to endpoints. > > However my issue is such that step 3 above "seems" to block until after > step 5. > > My Manager AMI connection reports success in step 3: > 21-Jan-16 01:02 pm asterisk_pa_list() manager_str Action: Originate[CR ][LF > ]Async: Yes[CR ][LF ]Channel: SIP/430[CR ][LF ] (truncated) > 21-Jan-16 01:02 pm asterisk_pa_list() manager_str return Response: > Success[CR ][LF ]Message: Originate successfully queued[CR ][LF ][CR ][LF ] > > I was expecting the jump into conference from step 3 to go ahead and do the > request - not wait till after step 5. > > Does this help? What am I not doing right so the calls in step 3 happen WAY > before the 10 seconds is complete?The problem we have is you are asking us to debug a description. That's usually almost impossible. Much easier to debug code, as it may or may not match your description! So we can offer more insight if you include information such as: 1. Relevant section of your dialplan. 2. The AGI code that does the origination. Presumably it is calling the AMI? In your example above, the Originate AMI has a Channel, but doesn't show any Context, Extension and Priority. Where is the channel supposed to go once the call to SIP/430 is answered? 3. The Asterisk "full" log, with at least verbose level 3, encompassing your attempt. 4. Anything else that you yourself would need to look at to debug the issue. Cheers Tony -- Tony Mountifield Work: tony at softins.co.uk - http://www.softins.co.uk Play: tony at mountifield.org - http://tony.mountifield.org
On Thursday 21 Jan 2016, Jerry Geis wrote:> >Not really. Very little info to go on so far. You need to give us > >more detail of what you are doing with AGI and AMI. > > Sorry - let me try again... > > > I am basically doing the following: > 1) calling a phone SIP/401 upon answer run an AGI for voice prompts etc... > to select AUDIO groups > 2) when done setup to return to the dialplan - exit AGI > 3) issue AGI that calls those groups selected (SIP/430 & SIP/431) at the > moment to bring into a conference. > 4) Wait 10 seconds > 5) jump SIP/401 into conference > 6) speak live to endpoints. > > However my issue is such that step 3 above "seems" to block until after > step 5. > > My Manager AMI connection reports success in step 3: > 21-Jan-16 01:02 pm asterisk_pa_list() manager_str Action: Originate[CR ][LF > ]Async: Yes[CR ][LF ]Channel: SIP/430[CR ][LF ] (truncated) > 21-Jan-16 01:02 pm asterisk_pa_list() manager_str return Response: > Success[CR ][LF ]Message: Originate successfully queued[CR ][LF ][CR ][LF ] > > I was expecting the jump into conference from step 3 to go ahead and do the > request - not wait till after step 5. > > Does this help? What am I not doing right so the calls in step 3 happen WAY > before the 10 seconds is complete?It's not *that* helpful, because you are playing your cards way too close to your chest; we don't even know what language you are using for your AGI. So the following may be no help at all to you, but is included anyway for the benefit of anyone else searching the archives a few years down the line. AGI scripts that do not need to interact with the dialplan anymore should fork() and then, in the parent process, exit(0). The child process must then close STDIN, STDOUT and STDERR as soon as possible; the dialplan will carry on executing when they are closed, and the child process is free to carry on doing its own stuff independently. In Perl, do *not* do it like this: fork && exit 0; close STDIN; close STDOUT; close STDERR; in case fork fails and returns an undefined value; the "child process" will continue under the parent's PID. Do it properly: if ($child_pid = fork) { # parent process exit 0; } elsif (defined $child_pid) { # child process close STDIN; close STDOUT; close STDERR; # carry on doing stuff } else { # fork failed die "Could not fork"; # tidy up mess as best we can }; PHP's pcntl_fork() returns -1 if it fails (process numbers are always positive). So the equivalent code in PHP would be: $child_pid = pcntl_fork(); if ($child_pid < 0) { // fork failed die("Could not fork"); } elseif ($child_pid) { // parent process exit(0); } else { // child process fclose(STDIN); fclose(STDOUT); fclose(STDERR); // carry on doing stuff }; -- AJS Note: Originating address only accepts e-mail from list! If replying off- list, change address to asterisk1list at earthshod dot co dot uk .