ARI question, what are __AST_CHANNEL_ALL_TOPIC channel_ids and how are they created?

Asterisk Asterisk APIs
1

We have some scenario where we connect via ARI, retrieve the ApplicationInfo and it reflects no channels, bridges, endpoints, or devices.

We send a call over to this Stasis application. It receives it and handles everything. Call completes and everything is cleaned up.

I’m force stopping this Stasis application to simulate a network cable being unplugged. All seems good.

However, when I reconnect and retrieve the Application object data again I’m seeing some things I don’t expect. What are the __AST_x_ALL_TOPIC values I see for channel_ids, bridge_ids, endpoint_ids, and device_names?

{
“name”:“MyAppName”,
“channel_ids”:[“__AST_CHANNEL_ALL_TOPIC”],
“bridge_ids”:[“__AST_BRIDGE_ALL_TOPIC”],
“endpoint_ids”:[“__AST_ENDPOINT_ALL_TOPIC”],
“device_names”:[“__AST_DEVICE_STATE_ALL_TOPIC”],
“events_allowed”:,
“events_disallowed”:
}

Am I doing something that’s causing these to be created? Off the top of my head, I can’t figure out what I may be doing to cause this. I manually run curl and wscat commands to try to replicate this behavior, but I haven’t been able to create these objects. That makes me think my code is somehow creating them, just not sure how.

Do I need to delete each of these?
Do I just ignore them?

2

They’re internally created and special, used for things that want to subscribe to receive all those event types. You don’t manage them.

1 Like
3

Thanks Joshua.

Based on them being managed internally.

When I reconnect (or connect), I will treat them as special and ignore them.

I’m working to make sure failover/recover cases clean things up. Example, instance A created channels, bridge, etc. Then, it loses power/crashes/etc. Fired back up, the information still is alive in Asterisk. We need to retrieve all the channels, bridges. Example, we are not receiving StasisStart because it was already assigned to our ARI Stasis application.

We retrieve the Application details for the Bridges list. This will only include bridges with channels in them (not ones that were created but crash happened before channel added to it).
Ignore the __AST_BRIDGE_ALL_TOPIC bridge id. All other bridges, there is no memory (crash/restart) of why these are around. Code should delete these bridges.

Retrieve a list of channels (which includes all channels in Asterisk). See if these have the DialPlan application set to Stasis. If so, check the DialPlanCEP app_data to see if it indicates our Stasis application name is in charge of this channel. If so, take appropriate action for this channel based on our Stasis application and what we want/need to do in this recovery condition.

Am I misunderstanding anything?

4

I don’t have experience in this area so can’t really comment on that aspect.

5

Thanks Joshua.

If there is ever a future wish, it would be nice for a reconnect to be able to know about bridges that it’s own Stasis application name is responsible for. Example being my application created bridges A, B, C, D. Only bridges B and C had channels added to them at the time of a crash. On a reconnect, retrieving the Application details we can see our bridge_ids (B and C) but not A and D. From my testing, I can add channels to A (even though I don’t have a way of knowing it exists from a reconnect). This indicates Asterisk did keep the bridge around, just no way for the Stasis application to know about it. (Unless I’m missing something in the API).

6

Feature requests can be submitted to Github[1].

[1] GitHub · Where software is built

7

Thanks Joshua.

Submitted a request