Versions Compared


  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: Migrated to Confluence 4.0

What is resource state communication?

Well, first, that's a complicated way to say what most people refer to as 'presence'. However, 'presence' implies a few concepts that aren't always relevant. In a more abstract sense, it is the knowledge about the state of a resource. A resource could be a device, a user, a conference bridge, or even an abstract entity created by an Asterisk SCF component to represent something that lives outside of Asterisk SCF. The state of the resource may be provided by it or determined by the actions being taken within the system by it.

Elements Involved


A producer provides state information about a resource.


A consumer takes state information and acts on it in some fashion.


An aggregator takes state information from potentially multiple producers and provides a 'view' of what the combined state is as a producer itself. How the 'view' is determined can be extremely specific to the environment.


The presence router acts as a central component where resource state information can be queried, subscribed to, and broadcast to. By acting as a central component through which all these actions flow, policy decisions can be enforced within it, or by hooks attached to Extension Points it provides.

Router Implementation

For our implementation of a presence router I expect IceStorm to be used as the method to broadcast state updates to consumers. I also expect that Extension Points will be created so individuals can influence subscriptions.


To allow presence to be extended the Status class has been declared as 'unsliceable'. This will allow implementations to extend and add additional implementation specific details. For example using SIP this may include SIP specific information.

Sequence Diagrams

Flow for a presence provider
Flow for a consumer pulling information
Flow for a consumer getting information pushed to it