[asterisk-users] is there some blocking in 11.21.0

A J Stiles asterisk_list at earthshod.co.uk
Fri Jan 22 03:14:43 CST 2016


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 .



More information about the asterisk-users mailing list