| Summary: | ASTERISK-21421: API Improvements: build out the concept of an endpoint in Stasis-Core | ||
| Reporter: | Matt Jordan (mjordan) | Labels: | Asterisk12 |
| Date Opened: | 2013-04-12 13:35:34 | Date Closed: | 2013-05-08 08:39:38 |
| Priority: | Major | Regression? | No |
| Status: | Closed/Complete | Components: | Core/Stasis |
| Versions: | Frequency of Occurrence | ||
| Related Issues: | |||
| Environment: | Attachments: | ||
| Description: | Stasis-HTTP will need the concept of an endpoint. This same concept is loosely defined already in the following manner:
* Devices and device state already exists in Stasis-Core (or will shortly) and are loosely related to the concept of an endpoint (although there is not a perfect 1 to 1 matching) * Many channel drivers raise AMI events that correspond to what would be an 'endpoint': ** {{chan_dahdi}} raises {{DAHDIChannel}} events and events related to spans ** {{chan_sip}} raises events for both registry events as well as {{PeerStatus}} events ** {{chan_iax2}} raises events for both registry and {{PeerStatus}} events as well ** {{chan_motif}} through {{res_xmpp}} raises status messages about Jabber Accounts In general, what we need is something that fulfills the following requirements: * A Stasis-Core cachable (that is, snapshot) object that provides basic properties of an endpoint, as well as its state. Some states may not make sense for all objects, but a reasonable cross-section of states should be defined. * Message technology specific properties should be conveyed in a JSON blob. * Stasis topics and messages for changes in state for an endpoint. | ||
| Comments: | |||