AORs (Address of Records)
What are AORs?
AORs are effectively an identifier for a device, or multiple devices, which is used for looking up how to contact them. Within Asterisk this is done in multiple places:
1. The Dialplan
The dialplan acts as a lookup mechanism for mapping a dialplan context and extension to another entity (it may be a physical device, or using chan_local it may be yet another dialplan context and extension). Depending on configuration this may even map to multiple entities.
2. Channel Drivers
In the past channel drivers have closely coupled an entity and how it is reached. This has made the lookup mechanisms within channel drivers extremely simple. The identifier provided leads directly to a single device, with contact information usually kept in the same place. While it has become common this is an implementation detail within the drivers themselves.
The new SIP channel driver, chan_pjsip, removes this direct association and introduces two new intermediaries: AORs and contacts.
AORs within chan_pjsip are an efficient manner to configure information about an entity that is reachable. It can be configured to allow registrations or limited to only statically specified addresses. As an AOR is separate from an endpoint it can be stored persistently in a different manner and does not waste memory when not used. AORs are associated with endpoints by configuring an endpoint with the names of them. An AOR may be associated with multiple endpoints.
Contacts contain the information about how to contact a SIP server. They are associated with AORs and can only be looked up using them.
Separating these concepts is a first step to making things aware that a single entity does not always map to a single device. As this is ultimately an internal implementation decision the deployer does *not* have to take advantage of it. The system can be configured to mirror the existing behavior present. For those who want to use it, though, it is there. A simplified configuration mechanism could also be created which hides the implementation completely and makes the deployer unaware.
Where the idea of an entity mapping to multiple devices becomes further complicated is device state. Device state has grown to encompass not just whether a device is reachable, but also the reasoning behind the state. It is this decision that is inherently business logic and which complicates the process.
Within Asterisk this aggregation and decision making is done in multiple places:
1. Extension state
There is aggregation logic which takes device state from multiple sources and determines the state of the extension. This is presently hard coded and is not configurable.
2. Device state within channel drivers
Some complex channel drivers, such as chan_sip, return descriptive information about their device state. This is accomplished by not just looking at device information but also active channels. This decision making, at least in chan_sip, has a few knobs which can be tweaked to alter the behavior (such as busy limit).
The new SIP channel driver, chan_pjsip, will not be immune to needing to do aggregation within itself at this time. Much like chan_sip if it wants to return descriptive state information it will have to be configurable. The configuration will determine what it returns to the device state core, and when. Device state will also extend to AOR level granularity, allowing not just the endpoint to be queried but also the AOR. For instances where multiple contacts exist for reaching an entity the presence of just one will be treated as the entity being reachable. If granular control is warranted individual endpoints and AORs can be used.
Further down the road I would envision that much of the aggregation that occurs will become a truly core function with configuration and caching, making its way out of the channel drivers by the publishing of events.
3. Distributed device state
There is aggregation logic which takes device state information from multiple servers and creates a single aggregated view of a device.
Unfortunately as discussed above there are limitations inherent with the core that limit how things are exposed within channel drivers. Despite these limitations it is still possible to configure things in such a manner to allow the flexibility that some deployments require while still exposing new functionality that has long since been requested.