Using the Asterisk ARI/API to "call" a channel

Hey Guys,

I am fairly new to Asterisk 13 and am working on a project to dynamically update a queue. Because the queue will change each day, I want to find a way to do this with the API instead of the CLI.

From what I have found this can be achieved by the following:

  • Create an exten in extensions.conf: exten => 7777,1,AddQueueMember(support, SIP/18)
  • Add this extension in the sip.conf.
  • Use the post request: POST https://{IP/Servername}:{Port}/ari/channels?endpoint=“SIP/7777”

Im able to use this application with console dial 7777@context, but if I try to use this post request in the API, I get the following message: {“message”: “Application or extension must be specified”}

It seems to me that there is something wrong in the configuration of the endpoint.

If I add an extension and context parameter to the post request, I receive an error:
{“error”: “Allocation failed”}

What is missing or am I doing something wrong?

Thanks in advance

There is nothing wrong in the configuration. Your request is just incomplete or improper. You’d need to show the precise HTTP request you are doing when you get the “Allocation failed”. As well it’s documented on the wiki[1] the specific options.

[1] Asterisk 18 Channels REST API - Asterisk Project - Asterisk Project Wiki

I tried two diffrent approaches:

  1. cURL
    curl -v -u asterisk:asterisk -X POST “http://{IP/Servername}:8088/ari/channels?context=wso2”
    → Allocation failed

curl -v -u asterisk:asterisk -X POST “http://{IP/Servername}:8088/ari/channels?endpoint=SIP/8888&extension=18&context=wso2”
→ Allocation failed

  1. Same result in SoapUI - doesnt matter if I send the parameters in the body or not.

If you try explicitly providing a priority does it work? Does anything show in the Asterisk console? Is SIP/8888 registered and reachable?

Adding a priority parameter results in the same error.

How can I access the logs in the Asterisk console? I have already set the console to debug 3.

SIP/8888 should be SIP/7777 (typo)

I think the endpoint should be reachable:
curl -v -u asterisk:asterisk -X GET "http://IP:8088/ari/endpoints/SIP/7777
< HTTP/1.1 200 OK
< Server: Asterisk/13.29.1
< Date: Fri, 12 Feb 2021 10:48:21 GMT
< Cache-Control: no-cache, no-store
< Content-type: application/json
< Content-Length: 90
<
{
“technology”: “SIP”,
“resource”: “7777”,
“state”: “unknown”,
“channel_ids”:
}

The wiki has a page talking about collecting debug information[1]. However, what does “sip show peer 7777” show in the CLI?

[1] Collecting Debug Information - Asterisk Project - Asterisk Project Wiki

If this is the only requirement, I’d suggest that ARI is the wrong API, and you should be using AMI.

Oh yes, I re-read the post a few more times and I think they’re wanting to originate to execute AddQueueMember.

@maethi If this is correct then AMI is a better option. There are queue actions for doing such things as adding a queue member[1].

[1] Asterisk 18 ManagerAction_QueueAdd - Asterisk Project - Asterisk Project Wiki

As for the “sip show peer 7777”:
sip show peer 7777

  • Name : 7777
    Description :
    Secret :
    MD5Secret :
    Remote Secret:
    Context : wso2
    Record On feature : automon
    Record Off feature : automon
    Subscr.Cont. : default
    Language : en
    Tonezone : ch
    AMA flags : Unknown
    Transfer mode: open
    CallingPres : Presentation Allowed, Not Screened
    Callgroup :
    Pickupgroup :
    Named Callgr :
    Nam. Pickupgr:
    MOH Suggest :
    Mailbox :
    VM Extension : asterisk
    LastMsgsSent : 0/0
    Call limit : 0
    Max forwards : 0
    Dynamic : Yes
    Callerid : “” <>
    MaxCallBR : 384 kbps
    Expire : -1
    Insecure : no
    Force rport : Yes
    Symmetric RTP: Yes
    ACL : No
    ContactACL : No
    DirectMedACL : No
    T.38 support : No
    T.38 EC mode : Unknown
    T.38 MaxDtgrm: 4294967295
    DirectMedia : No
    PromiscRedir : No
    User=Phone : No
    Video Support: No
    Text Support : No
    Ign SDP ver : No
    Trust RPID : No
    Send RPID : No
    Path support : No
    Path : N/A
    TrustIDOutbnd: Legacy
    Subscriptions: Yes
    Overlap dial : Yes
    DTMFmode : rfc2833
    Timer T1 : 500
    Timer B : 32000
    ToHost :
    Addr->IP : (null)
    Defaddr->IP : (null)
    Prim.Transp. : UDP
    Allowed.Trsp : UDP
    Def. Username: asterisk
    SIP Options : (none)
    Codecs : (alaw|gsm|g722|g726)
    Auto-Framing : No
    Status : UNKNOWN
    Useragent :
    Reg. Contact :
    Qualify Freq : 60000 ms
    Keepalive : 0 ms
    Sess-Timers : Accept
    Sess-Refresh : uas
    Sess-Expires : 1800 secs
    Min-Sess : 90 secs
    RTP Engine : asterisk
    Parkinglot :
    Use Reason : No
    Encryption : No
    RTCP Mux : No

Regarding AMI:

Mabye I need to explain my Use Case furhter. We have a Google Calendar for the Support Team. For each day there are two calendar entries (two support roles + assignees). We collect this data every morning using the Google API and are now looking for a way to alter the queues based on this information. Atm we manually do this with the CLI but we want to change that. The Assignees are subject to change on weekly or daily basis.

Is this possible to do with AMI? Or am I right in thinking that we need to use the ARI?

Nothing makes me think that AMI is not the better option.

As I see it, you are having to bend ARI in order to use that.

AMI would be a better for this as @david551 stated.

Thank you for your help!

I have looked into AMI and during the research I found the Asterisk Call Files. This method would be perfect for our setup. From what I gathered, it is possible to add / remove queue members with this method.

Here the example form the documentation:

To execute an application:

  • Application: <appname> - The application to execute
  • Data: <args> - The application arguments

I wasnt able to get it to work yet. I want to do this application: AddQueueMember(support,SIP/24)

How do transfer this to the call file? (args)

Again this needs a dummy channel and is a contorted way of doing it.

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.