What's wrong with Originate?

Question

PHP

There was a need to create a callback form on the company's websites.
For implementation, we decided to use the Originate command for our Asterisk.
I asked the admin to create an AMI user and upload data for the Originate command.
For example, a client with the number 89111234567 submitted a form and is waiting for a call from a manager with an extension of 1234

require_once "./vendor/autoload.php";

$options = [
    'host' => 'asterisk_host',
    'scheme' => 'tcp://',
    'port' => 5038,
    'username' => 'username',
    'secret' => 'secret',
    'connect_timeout' => 15000,
    'read_timeout' => 15000
];

$ami = new \PAMI\Client\Impl\ClientImpl($options);
$originate = new \PAMI\Message\Action\OriginateAction('Local/[email protected]');

$originate->setCallerId('89111234567');
$originate->setContext('from-office');
$originate->setExtension('89111234567');
$originate->setTimeout(15000);
$originate->setPriority(1);
$originate->setAsync(false);

$message = $ami->send($originate);

if($message->isSuccess()){
    //
}else{
    //
}

The point is that it doesn't work that way. After sending the command, there is a call to the manager, it is displayed on the phone [phone] the subscriber is not matched), as soon as the manager picks up the phone everything ends.
If you specify not 89111234567 as the CallerId, but any internal number, for example, 2222 or its own 1234, then everything works fine, but the manager thinks that Vasya Pupkin is calling him.
The admin broke his whole head, but has not yet offered a solution. I am a person far from asterisk and I can’t clarify either. Tell me, what could be the snag?

Answer 1

Most likely, the problem lies in the incorrectly specified channel - the local channel is simply not able to go somewhere outside the Asterisk, so external calls do not work, but internal ones go.
Usually the channel looks like "SIP/#FROM#".

Answer 2

I didn’t understand why the answer was deleted ....
Let the admin remove the full call logs (sip set debug on or TCP dump).
Then look for at what point it breaks and by whom the break was made.
It's just that no one is dumping anyone.
If the operator (yours or the client) does not miss the call, then he does not like something.
Perhaps just the same callerdid goes to both channels the same, and the operator (client) does not miss such a call (it turns out that the client calls himself).
It is also possible that the operator (which provides you with a connection) forbids setting any callerid, because this is actually from the category of semi-VIP functions.

Answer 3

Local/[email protected]/n
Try adding /n at the end, this prevents the LocalChannel from killing itself immediately while the second subscriber is being dialed.