ARI parameters in query string

[erduende]

Hello, we are integrating ari-proxy in one of our projects to provide HA to our ARI applications. We have noticed that the ari client implementation is not sending parameters in query string as is referenced in asterisk documentation.

In some cases it is working because Asterisk searches for parameters in body and query string, but in other cases, such externalMedia endpoint, it seems to require parameters as query string and it does not work.

Is there a way to pass parameters in query string as it is required by Asterisk ARI API?

Thank you in advance, you are making a great work.

[Ulexus]

I have wondered about that more than a couple times, and dismissed it as a case of "it's working, so why 'fix' it" kind of thing. It sounds like it is no longer "working" for all cases, so yeah, we should definitely fix it.

[erduende]

We would like yo help with a pull request but we don't have experience in Go. We hope you can fix it, so externalMedia can be used.

Thank you

[illarion]

I have faced the same issue - after hours of debugging the values I submit to an ExternalMedia request, I've realized that asterisk is just not expecting parameters in the body. I can make a PR fixing that, but I need to know, is client/native autogenerated or handwritten?

[hwiorn]

I got a same problem. After some testing, I found the cause is that the go-ari module uses whole ExternalMediaOptions as a request-body.

ari/client/native/channel.go

Lines 426 to 428 in a0b3688

	return ari.NewChannelHandle(k, c, func(ch *ari.ChannelHandle) error {
	return c.client.post("/channels/externalMedia", nil, &opts)
	}), nil

But Asterisk expects a Variables field only as the request-body because only the Variables field is a JSON format. Other fields need to be as query parameters in a URL. So the asterisk always responds as 400 Bad Request. Actually, I got to recognize the explanation of externalMedia parameters in the asterisk official document is a misunderstandable.

All parameters except variables can be supplied as part of the POST's query string. Because it's a JSON object, variables MUST be supplied on the request body. This is similar to other channel creation calls.

I checked ari-client(official nodejs module) for a correct implementation and the module parses the swagger api directly and uses it for request. So the ari-client module doesn't have any issue.

I don't know what asterisk version was compatible with the current implementation.
I'm testing Asterisk 18(LTS) and I think the externalMedia implementation is wrong.

For example, It needs to be changed like below.

	return ari.NewChannelHandle(k, c, func(ch *ari.ChannelHandle) error {
		base, err := url.Parse("/channels/externalMedia")
		if err != nil {
			return err
		}

		// Query type parameters
		params := url.Values{}
		params.Add("app", opts.App)
		params.Add("external_host", opts.ExternalHost)
		params.Add("encapsulation", opts.Encapsulation)
		params.Add("transport", opts.Transport)
		params.Add("connection_type", opts.ConnectionType)
		params.Add("format", opts.Format)
		params.Add("direction", opts.Direction)
		params.Add("data", opts.Data)
		base.RawQuery = params.Encode()

		return c.client.post(base.String(), nil, variables) // pass by argument
	}), nil

[Ulexus]

Ah, nice find! Thanks. Would you be willing to package that up as a PR?

[hwiorn]

@Ulexus
I've made a PR for externalMedia.
But I think the externalMedia is just one of this issue.
I noticed a call-originate API implementation is same.
I think you have to check these creation-calls API implementations for the latest Asterisk according to the document.

All parameters except variables can be supplied as part of the POST's query string. Because it's a JSON object, variables MUST be supplied on the request body. This is similar to other channel creation calls.

[Ulexus]

I agree; I think the determination really should be done automatically based on the swagger spec. That sounds like a job for the code generation tool (which is currently handling the parsing of the spec). It is probably easiest to just have a lookup table for these.