Dynamic WebSocket URL/port for External Media at channel creation (like UDP host/port)

Asterisk Asterisk APIs
1

Background

When using ARI External Media over WebSocket (`/ari/channels/externalMedia` with `transport: websocket`), the destination WebSocket server must be pre-configured in `websocket_client.conf` and referenced via a static `connectionId` at channel creation time. There is currently no way to supply or override the target URL, port, or TLS settings dynamically in the API request itself.

This is in contrast to the UDP transport, which already supports passing `host` and `port` directly as parameters at channel creation — making it possible to route audio to any destination at runtime without any static config.

Feature Request

Extend the WebSocket external media transport to accept an optional `parameters` object in the channel creation request, supporting fields such as:

  • `url` — target WebSocket server URL (`ws://` or `wss://`)
  • `port` — destination port (if not embedded in the URL)
  • `tls` — TLS options (e.g. enable/disable, cert/key/ca paths, `rejectUnauthorized`)

When these parameters are provided, they should take precedence over the static `connectionId` lookup — making `connectionId` optional rather than required for WebSocket external media. This keeps the change fully backward-compatible.

Proposed API shape
POST /ari/channels/externalMedia
{
“app”: “my-app”,
“transport”: “websocket”,
“parameters”: {
“url”: “wss://media.example.com:8765/stream”,
“tls”: true
}
}

Use case

In multi-tenant or dynamic call routing scenarios, the target media server (e.g. a transcription, recording, or AI voice processing endpoint) is often determined at call time. Pre-defining every possible destination in `websocket_client.conf` is not scalable. This feature would allow the same dynamic routing flexibility that UDP already provides, over WebSocket.

Why this matters

WebSocket transport is increasingly preferred over UDP for external media due to better connection management and framing. Bringing it to feature parity with UDP on this front would make it significantly more practical for production deployments.

Looking forward to thoughts from the community and maintainers. Happy to help test or contribute if there is interest in moving this forward.

I have raised the Feature Request for the same also

2

I believe I’ve mentioned it before, but there’s a separate repo for feature requests:

3

My bad thanks