ExternalMedia + AudioSocket on Asterisk 22?

Asterisk Asterisk APIs
1

Seems there is a bug with ExternalMedia + AudioSocket on asterisk 22:

core show version
Asterisk 22.8.0 built by root @ test on a x86_64 running Linux on 2026-01-23 12:11:36 UTC

curl -v -u asterisk:asterisk -X POST “http://127.0.0.1:8088/ari/channels/externalMedia” -H “Content-Type: application/json” -d ‘{ “app”: “test”, “external_host”: “127.0.0.1:9999”, “format”: “ulaw”, “transport”: “tcp”, “encapsulation”: “audiosocket”, “connection_type”: “client”, “direction”: “both” }’
Note: Unnecessary use of -X or --request, POST is already inferred.

Trying 127.0.0.1:8088…

Connected to 127.0.0.1 (127.0.0.1) port 8088 (#0)

Server auth using Basic with user ‘asterisk’

POST /ari/channels/externalMedia HTTP/1.1
Host: 127.0.0.1:8088
Authorization: Basic YXN0ZXJpc2s6YXN0ZXJpc2s=
User-Agent: curl/7.76.1
Accept: /
Content-Type: application/json
Content-Length: 178

Mark bundle as not supporting multiuse
< HTTP/1.1 500 Internal Server Error
< Server: Asterisk
< Date: Sun, 01 Mar 2026 11:53:22 GMT
< Cache-Control: no-cache, no-store
< Content-type: application/json
< Content-Length: 78
<
{
“message”: “An internal error prevented this request from being handled”

Connection #0 to host 127.0.0.1 left intact
}

Doing same on asterisk version 20 gives different result - “data can not be empty” which is ok:

core show version
Asterisk 20.4.0 built by root @ test on a x86_64 running Linux on 2023-08-20 16:35:41 UTC

curl -v -u asterisk:asterisk -X POST “http://127.0.0.1:8088/ari/channels/externalMedia” -H “Content-Type: application/json” -d ‘{ “app”: “test”, “external_host”: “127.0.0.1:9999”, “format”: “ulaw”, “transport”: “tcp”, “encapsulation”: “audiosocket”, “connection_type”: “client”, “direction”: “both” }’

Note: Unnecessary use of -X or --request, POST is already inferred.

Trying 127.0.0.1:8088…

Connected to 127.0.0.1 (127.0.0.1) port 8088 (#0)

Server auth using Basic with user ‘asterisk’

POST /ari/channels/externalMedia HTTP/1.1
Host: 127.0.0.1:8088
Authorization: Basic YXN0ZXJpc2s6YXN0ZXJpc2s=
User-Agent: curl/7.76.1
Accept: /
Content-Type: application/json
Content-Length: 178

Mark bundle as not supporting multiuse
< HTTP/1.1 400 Bad Request
< Server: Asterisk
< Date: Sun, 01 Mar 2026 11:42:51 GMT
< Cache-Control: no-cache, no-store
< Content-type: application/json
< Content-Length: 40
<
{
“message”: “data can not be empty”

Connection #0 to host 127.0.0.1 left intact
}

Am I doing something wrong or there is really an issue?
Thanks in advance.

2

We’ve had no reports, and there are tons of people using it. I’d suggest actually looking at the Asterisk side and seeing if anything stands out.

4

Hello, thank you for your answer, can you confirm that running this CURL request (considering ARI configured correctly) is a valid test for ARI externalMedia → audioScoket to prove working?
Being testing these deeply on different installations like freepbx:
Asterisk 22.6.0 built by jenkins @ 0ea5ef11b0b7 on a x86_64 running Linux on 2025-11-03 07:19:51 UTC (debian12.12)
or pure asterisk:
Linux playtest 5.14.0-354.el9.x86_64 #1 SMP PREEMPT_DYNAMIC Thu Aug 10 21:06:12 UTC 2023 x86_64 x86_64 x86_64 GNU/Linux (CentOS Stream release 9)
and nodejs/python stasis apps working correctly on asterisk version 20 do not work any more on version 22, narrowed down the problem to that very CURL.
Setting something like core set debug 10 does not shed any light

5

I don’t use audiosocket so can’t answer further beyond my initial response and whether anything has been reported in the issue tracker. Those who use it may respond.

6
7

Thank you,
in spite of ‘data’ field is not required - for this case it is, proper working curl format is:
curl -v -u asterisk:asterisk -X POST “``http://127.0.0.1:8088/ari/channels/externalMedia”`` -H “Content-Type: application/json” -d ‘{ “app”: “translator”, “external_host”: “127.0.0.1:9999”, “format”: “ulaw”, “transport”: “tcp”, “encapsulation”: “audiosocket”, “connection_type”: “client”, “direction”: “both”, “data”: “f353ca91-4fc5-49f2-9b9e-304f83d11914”}’