8 thoughts on - Is There Some Blocking In 11.21.0

• Use Priority: to begin at the dialplan step after the Wait() command.

• *>> >>* At one point I have a 10 second delay “Wait(10)” in the dialplan…
  *>>* During this time it “seems” that if I then connect with the manager
  *>>* interface
  *>>* and place a call that nothing happens till the 10 seconds is done…
  *>> >>* I am requesting Async yes…
  *>>* manager_str Action: Originate[CR ][LF ]Async: Yes[CR ][LF ]Channel:
  *>>* SIP/430[CR ][LF] (this is the first part of the AMI string)
  *>> >>* How can I get past that… I want the other call to happen right away.
  *

  Thanks AJS – Sorry, I was not clear enough.

  Its not the command right after the Wait(10) that is being delayed…. I have another process that issuing the commands to the AMI.

  Its basically like this:

  AGI( run to bring items into conference SIP/100 & SIP/101 lets say)
  Wait(10)
  ConfBridge(to take this user into above conference)

  But the SIP/100 and SIP/101 calls do not take place until a second delay.

  Why are the SIP/100&SIP/101 calls delayed during the Wait(10) ?

  Thanks

  Jerry

• In article , Jerry Geis 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?

  Cheers Tony

• I should have said “first time” trying this.

  Any thoughts?

  Jerry

• In article , 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.

  Cheers Tony

• 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

• In article , Jerry Geis wrote:

  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

• 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 };