search

nvisibleinc / go-ari-library

Library for consuming and producing ARI events from the client side
Apache License 2.0
8 stars 6 forks source link

Would ServerID be better in AppStart? #2

Closed skrusty closed 9 years ago

skrusty commented 9 years ago

Currently the AppStart event doesn't contain the ServerID, but instead it's located in the Event struct.

Would this not be better off in AppStart, as once an event subscription has been setup, the proxy/ServerID wont change.

Also, this allows for the serverid to be queried before the initial StasisStart event.

blitzrage commented 9 years ago

I've created a couple of pull requests that might satisfy this issue:

skrusty commented 9 years ago

Looks right!

Are you going to continue to push the server id during each subsequent message? The only reason i could see to do this, is if it's possible for the sending proxy to change mid conversation. I suppose that's not totally out of the question, but just unlikely.

blitzrage commented 9 years ago

In this case, the ServerID is actually the identifier for the Asterisk instance and not the proxy. While you may have a 1:1 relationship between Asterisk and proxy, that's not necessary of course, so even if the proxy changed mid conversation, the ServerID should still be the same.

blitzrage commented 9 years ago

OK I totally misspoke there after reviewing the code. I forgot that the intent of the ServerID was to be somewhat dynamic, but in this case it is actually static, as the proxy must be deployed in a 1:1 relationship because we haven't added any of the routing logic to allow a proxy to handle multiple ARI instances.

One of the thoughts here was then to perhaps still have a ServerID which might continue to identify the endpoint for the applications (the proxy) and then the proxy would have a DialogID <-> ARI_Instance_ID mapping of some sort to allow the routing of application dialogs back to the appropriate ARI instance.

From there we could start to do all sorts of complex things, such as dynamically "transferring" or migrating calls from one Asterisk server to another, without the application really even needing to be aware of it since it would just track the dialog. At that point you could API expose some "move" commands on the proxy side, move calls on the Asterisk side of things, and just update the ARI_Instance_ID <--> DialogID mappings in the proxy memory.

You do bring up an interesting point about the ServerID maybe changing (e.g. the proxy going down or being migrated away). In a container environment where maybe you have 2-3 ARI proxies running, and want to upgrade them, you would need to migrate the information from one proxy to another.

This is clearly a "down the road" enhancement, but thanks for asking the question. It brought up a lot of thinking in this area. For now, the ServerID is going to just come from the configuration file for the proxy, which will essentially be the ARI instance as well in this case.

blitzrage commented 9 years ago

I've merged the appropriate changes now. Closing issue.