When the connection is first established, there may be calls in the system. For example, there could be calls that were assigned to this stasis application. Someone accidentally unplugs the power to the ARI/Stasis/golang application. Asterisk keeps the calls going to the ARI/Stasis/golang application control.
Now, someone powers up the ARI/Stasis/golang application. First thing it should do is retrieve a list of Channels. Not all the channels Asterisk passes back for the ARI Stasis channel list may belong to controlled by this application. In the Channel List of data, key's app is set to the stasis app (even though that is not what Asterisk is passing back). As a result, it makes it appear we have ability to control the call with ARI, but we do not.
In my testing, Asterisk does not send new StasisStart events for the reconnection. This is why the ARI application needs to retrieve the channel list and filter them to know what it is responsible for.
Not sure yet, but it may also be nice to have the app_name and app_data included in the dialplan. That way, when we reconnect after the outage
Here is what I see from the CyCoreSystems ARI after retrieving the channels list.
Channel[0] (1675093673.35) =
key:<kind:"channel" id:"1675093673.35" node:"00:15:5d:20:64:0e" app:"a2519b4b-4d90-4d18-906b-717d02f8d569" >
id:"1675093673.35"
name:"Local/10000@IS-00000004;2"
state:"Up"
caller:<name:"LocalTest" number:"9000" >
connected:<name:"LocalTest" number:"9000" >
creationtime:
dialplan:<context:"IS" exten:"10000" priority:33 >
Channel[1] (1675093673.34) =
key:<kind:"channel" id:"1675093673.34" node:"00:15:5d:20:64:0e" app:"a2519b4b-4d90-4d18-906b-717d02f8d569" >
id:"1675093673.34"
name:"Local/10000@IS-00000004;1"
state:"Up"
caller:<name:"LocalTest" number:"9000" >
connected:<name:"LocalTest" number:"9000" >
creationtime:
dialplan:<context:"IS" exten:"createcall" priority:23 >
Notice the channel 1675093673.34 keys shows the app as a2519b4b-4d90-4d18-906b-717d02f8d569
Below is the same data retrieved via a curl command. The app is actually AGI.
I suspect channels retrieved could also be in the asterisk dial plan steps (not Stasis, ARI, but hundreds of other possibilities).
Note: I believe the same may apply to bridges. When first connecting, should retrieve a list of existing bridges. Filtering based on what we control via Stasis and what belongs to other Stasis (or non-Stasis) applications.
When the connection is first established, there may be calls in the system. For example, there could be calls that were assigned to this stasis application. Someone accidentally unplugs the power to the ARI/Stasis/golang application. Asterisk keeps the calls going to the ARI/Stasis/golang application control.
Now, someone powers up the ARI/Stasis/golang application. First thing it should do is retrieve a list of Channels. Not all the channels Asterisk passes back for the ARI Stasis channel list may belong to controlled by this application. In the Channel List of data, key's app is set to the stasis app (even though that is not what Asterisk is passing back). As a result, it makes it appear we have ability to control the call with ARI, but we do not.
In my testing, Asterisk does not send new StasisStart events for the reconnection. This is why the ARI application needs to retrieve the channel list and filter them to know what it is responsible for.
Not sure yet, but it may also be nice to have the app_name and app_data included in the dialplan. That way, when we reconnect after the outage
Here is what I see from the CyCoreSystems ARI after retrieving the channels list. Channel[0] (1675093673.35) = key:<kind:"channel" id:"1675093673.35" node:"00:15:5d:20:64:0e" app:"a2519b4b-4d90-4d18-906b-717d02f8d569" > id:"1675093673.35" name:"Local/10000@IS-00000004;2" state:"Up" caller:<name:"LocalTest" number:"9000" > connected:<name:"LocalTest" number:"9000" > creationtime:
dialplan:<context:"IS" exten:"10000" priority:33 >
Channel[1] (1675093673.34) =
key:<kind:"channel" id:"1675093673.34" node:"00:15:5d:20:64:0e" app:"a2519b4b-4d90-4d18-906b-717d02f8d569" >
id:"1675093673.34"
name:"Local/10000@IS-00000004;1"
state:"Up"
caller:<name:"LocalTest" number:"9000" >
connected:<name:"LocalTest" number:"9000" >
creationtime:
dialplan:<context:"IS" exten:"createcall" priority:23 >
Notice the channel 1675093673.34 keys shows the app as a2519b4b-4d90-4d18-906b-717d02f8d569 Below is the same data retrieved via a curl command. The app is actually AGI.
I suspect channels retrieved could also be in the asterisk dial plan steps (not Stasis, ARI, but hundreds of other possibilities).
[ { "id":"1675093673.35", "name":"Local/10000@IS-00000004;2", "state":"Up", "protocol_id":"", "caller":{"name":"LocalTest","number":"9000"}, "connected":{"name":"LocalTest","number":"9000"}, "accountcode":"", "dialplan":{"context":"IS","exten":"10000","priority":33,"app_name":"Stasis","app_data":"a2519b4b-4d90-4d18-906b-717d02f8d569"}, "creationtime":"2023-01-30T09:47:53.350-0600", "language":"en" }, { "id":"1675093673.34", "name":"Local/10000@IS-00000004;1", "state":"Up", "protocol_id":"", "caller":{"name":"LocalTest","number":"9000"}, "connected":{"name":"LocalTest","number":"9000"}, "accountcode":"", "dialplan":{"context":"IS","exten":"createcall","priority":23,"app_name":"AGI","app_data":"agi:async"}, "creationtime":"2023-01-30T09:47:53.350-0600", "language":"en" } ]
Note: I believe the same may apply to bridges. When first connecting, should retrieve a list of existing bridges. Filtering based on what we control via Stasis and what belongs to other Stasis (or non-Stasis) applications.