Running into an issue where a ARI originated channel is not hitting the hangup (h) extension. I’ve posted my ARI requests and actions below. My expectation would be that after the ‘continue’ that channel exits ARI and now running the 1234@default dialplan. So if the end user hangs up at this time, my understanding is that the channel would run the hangup extension for the current context. Is this a bug or maybe a misunderstanding of the originates’s app parameter?
I’m aware that the originate can accept extension and context as parameters. When using these parameters, it functions as expected. However, I have a few other requests between these two, and wanted to provide a minimum failed example.
POST /ari/channels/my-channel-id-1234
Params:
endpoint=SIP/6001
app=my-stasis-app
POST /ari/channels/my-channel-id-1234/continue
Params:
extension=1234
context=default
priority=1
Called user (SIP/6001) hangs up here. Expected hangup extensions to run, but doesn’t.
My expectation would be that it would be hung up. Execution of the h extension requires that there be something running dialplan for the channel. In fact, in may cases it is the diaplan interpreter that actually initiates the jump to the h extension.
my-channel-id-1234 is an opaque name and no part of it has any meaning to the Asterisk core, except for the name of the whole being the name of the channel. 1234 is not an extension number.
If you want to do anything non-trivial with originate (CLI, AMI, or ARI), or call files, yo need to use the extension format, not the application format.
Execution of the h extension requires that there be something running dialplan for the channel. In fact, in may cases it is the diaplan interpreter that actually initiates the jump to the h extension.
That is my understanding as well. The ‘continue’ request should exit the Stasis application (my-stasis-app) and continues the execution in the dialplan. Additionally, running ‘core show channel …’ shows the created channel in 1234@default context.
If you want to do anything non-trivial with originate (CLI, AMI, or ARI), or call files, you need to use the extension format, not the application format.
I’m not familiar with the extension format, can you elaborate?
To continue in the dialplan, it would need to have been in it in the first place. What this will actually mean, I believe, is that the stasis application will return with a zero return code (which it appears that it always does, regardless of why it terminates!), which, if it had been run from the dialplan, would cause the dialplan to continue, but it hasn’t been run from the dialplan.
Is the setting of extension and context actually documented? I guess it needs to put something there, but using the last part of the channel name seems strange. For channels created normally, that is a tie breaker, so essentially random, for many channel types, or the originating line number, for DAHDI, where only one channel can exist at a time for an endpoint.
The extension format is when you use context, extension and, if allowed, priority, rather than application and application data. As it says in
If you were expected to rely on the extension being set from part of the channel ID, I would have hoped that that article would have stated that. However, I find a lot of detail missing in the wiki, partly because a lot of it is not real wiki, but is locked to comments in the code, although I’m not sure that is the case for this page.