Create softphone answer button using AMI bridge action


As the title suggests, I am trying to make a softphone’s answer function using the AMI’s bridge action.

Below is my code and AMI websocket server used amiws. (GitHub - staskobzar/amiws: Asterisk Management Interface (AMI) to Web-socket proxy)

== Part of HTML ==

Softphone Login

== Part of JS ==

const socket = new WebSocket(‘ws://XXX.XXX.XXX.XXX:8000’);
socket.onopen = function() {

const login = {
action: ‘login’,
username: ‘XXX’,
secret: ‘XXX’

let loginEndpoint;
let answerChannel1;
let answerChannel2;

socket.onmessage = function(event) {
const eventData = JSON.parse(;
const parseData =;

if (parseData.Event === "DialState" && parseData.DestExten === document.getElementById('loginEndpointInput').value) {    
    answerChannel1 = parseData.DestChannel;
    answerChannel2 = parseData.Channel;
    console.log('channel1: ' + answerChannel1 + ' channel2: ' + answerChannel2);


function login(){
loginEndpoint = “PJSIP/” + document.getElementById(‘loginEndpointInput’).value;
console.log('Login Endpoint: ’ + loginEndpoint);

function answerCall() {
const bridge = {
action: ‘bridge’,
channel1: answerChannel1,
channel2: answerChannel2
console.log('Answercall: ’ + answerChannel2 + ’ to ’ + answerChannel1);

For example, when PJSIP/1102 calls PJSIP/1101, the softphone receives the channels of PJSIP/1101 and PJSIP/1102 and sends a bridge action.


The answer function does not work with the log as below.

-- Executing [1101@Long-Distance:1] NoOp("PJSIP/1102-0000004c", "") in new stack
-- Executing [1101@Long-Distance:2] Dial("PJSIP/1102-0000004c", "PJSIP/1101") in new stack
-- Called PJSIP/1101
-- PJSIP/1101-0000004d is ringing

== Everyone is busy/congested at this time (1:0/0/1)
– Executing [1101@Long-Distance:3] Goto(“PJSIP/1102-0000004c”, “Internal-Main,1101,1”) in new stack
– Goto (Internal-Main,1101,1)
– Executing [1101@Internal-Main:1] Verbose(“PJSIP/1102-0000004c”, “1, “User 1102 dialed an invalid number.””) in new stack
“User 1102 dialed an invalid number.”
– Executing [1101@Internal-Main:2] Playback(“PJSIP/1102-0000004c”, “pbx-invalid”) in new stack
> 0x7fe66404c850 – Strict RTP learning after remote address set to:
– <PJSIP/1102-0000004c> Playing ‘pbx-invalid.gsm’ (language ‘en’)
> 0x7fe66404c850 – Strict RTP switching to RTP target address 192.168.1.XXX:4016 as source
– Channel PJSIP/1101-0000004d joined ‘simple_bridge’ basic-bridge
– Executing [h@Internal-Main:1] Hangup(“Surrogate/PJSIP/1102-0000004c”, “”) in new stack
== Spawn extension (Internal-Main, h, 1) exited non-zero on ‘Surrogate/PJSIP/1102-0000004c’
– Channel PJSIP/1102-0000004c joined ‘simple_bridge’ basic-bridge
> 0x7fe66404c850 – Strict RTP learning complete - Locking on source address 192.168.1.XXX:4016

Can someone please help me?

Is the softphone still answering according to the SIP protocol? That has to happen regardless. Asterisk can’t force that to happen.

The softphone in this code does only call control. The actual registered phone is MicroSIP (

That doesn’t really change my previous response.

Do you know of another way to answer using AMI?

Please help me.

You’re going to need to explain more about what you are doing and what all is involved. For an outgoing call, Asterisk can’t answer that call if that’s what you are trying to do.

The standard way of doing click to call, with SIP phones, is to disable the safeties on the phone that prevent eavesdropping, and then add the proprietary SIP header, typically telling the phone to answer after a number of rings. There are de facto standards for this, but I don’t think there are any official ones.

Actually, there is an RFC for this, but it isn’t what people normally implement. These are de facto ones that one brand implements: Yealink Support

If you search for click to call, you should find many worked examples.

I would suggest using the standard AMI (port 5038) protocol, as alternative protocols are likely to be poorly maintained, and unfamiliar to people here.

I’m making a web interface to control a hard phone (any kind) with a screen capture. The reason to use a hard phone rather than a soft phone such as MicroSIP is to prepare for a PC disaster.

Asterisk can’t explicitly “control” any phone. You can perform certain actions and move channels around or hang them up because those are things under the control of Asterisk, but for example you can’t force a phone to answer using AMI.

Yes, I understand. Thank you.

If I create an application that controls a hard phone with ARI, can I not interact with the existing Queue() or MixMonitor()?

You can direct channels into the dialplan from your ARI application, but you can’t directly interact with Queue or MixMonitor.

The reason is that the channel is in stasis, right?


Then, it would be impossible to create an application that controls a hard phone using ARI, AGI, or AMI.

For different definitions of “control”, yes. Ultimately in Asterisk you’re not controlling a phone. You’re controlling a channel, which is limited.

Thank you !

Maybe you need to be a bit more explicit about what you mean by “control a
hard phone”. So far you have asked specifically about Queue() and Mixmonitor()
and the answer is that you can’t interact directly with those.

However, if you want to do other things with the phone, they might be

What are you actually trying to achieve?


ARI is not appropriate.

For control, AMI is likely to be more appropriate, but you cannot, as you originally requested, simulate the user pressing an answer button on a phone, as phones don’t allow that level of remote control.

MixMonitor can be controlled with AMI. Control of a queue through AMI is limited, although you can get a little further by using AMI to direct the call into sections of dialplan that then invoke the Queue applicatoin

It looks like OP is trying to get Asterisk to “tell” the phone to answer the call.

Some phones allow you to send the Alert-Info header to which it will react acoording to the content of the header, it may be a different or silent ringtone, auto anser etc.

Then there are very few brands that allow you to send a SIP NOTIFY to answer, dial, etc. So for those phones, you should br able to send a NOTIFY via AMI.

But again, it is up to the phone to support it.