You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Sep 19, 2019. It is now read-only.
The queues that represent a session within the proxy don't get cleaned up after the call has ended or left the ari application.
When should a queue be deleted?
You can still receive events after the channel has left your application, that's valid. But should you receive anything once the application has both left and hungup?
For example, if you do an originate, and bridge, then hangup, your applicaiton will have left, will have hangup, but it's valid that you might still get events for the hangup on the originated channel?
The text was updated successfully, but these errors were encountered:
Thinking about this more, seems to make sense that the client cleans up a queue, as technically only it can decide if it no longer wants to listen for any events or push actions to the proxy.
With that in mind, how would the client and proxy co-ordinate the closing of a dialogue? Does RMQ notify you of a closed queue? Would there just be some catchable exception on the proxy?
Anyway, food for thought.
Sign up for freeto subscribe to this conversation on GitHub.
Already have an account?
Sign in.
The queues that represent a session within the proxy don't get cleaned up after the call has ended or left the ari application.
When should a queue be deleted?
You can still receive events after the channel has left your application, that's valid. But should you receive anything once the application has both left and hungup?
For example, if you do an originate, and bridge, then hangup, your applicaiton will have left, will have hangup, but it's valid that you might still get events for the hangup on the originated channel?
The text was updated successfully, but these errors were encountered: