[asterisk-dev] What's an AOR?

[Joshua Colp]

Olle E. Johansson wrote:
> 23 maj 2013 kl. 16:48 skrev Mark Michelson<mmichelson at digium.com>:
>
>> On 05/22/2013 01:42 PM, Olle E. Johansson wrote:
>>> 22 maj 2013 kl. 20:18 skrev Mark
>>> Michelson<mmichelson at digium.com>:
>>>
>>>> This is not correct. The replacement for peer/user is the type
>>>> "endpoint". The term "endpoint" is generic enough that it can
>>>> refer to any sort of logical SIP device with which Asterisk
>>>> will be communicating.
>>>>
>>>> An endpoint may be configured to have any number of aors
>>>> associated with it. In turn, each aor may have multiple
>>>> contacts bound to it. This allows a hierarchical structure that
>>>> decouples endpoints from locations.
>>> Mark, Since I obviously have misunderstood this architecture -
>>> can you please describe how this is configured and use cases for
>>> this structure. Also, how it is handled by the core pbx - since
>>> you now can have multiple devices for one dialstring entry?
>>>
>>> Thanks, /O
>> Sure thing. Let's consider a business where you and I work together
>> as support technicians. We each have a desk phone (an "endpoint" by
>> Asterisk definition), so we initially set up a very simple
>> configuration like so:
>
> Thanks. I do understand why the code have all this capability, but I
> fail to understand why we can't make a configuration that makes more
> sense from an Asterisk admin standpoint.

The configuration mechanism available right now is a direct mapping into 
the implementation objects in memory. This gives you maximum 
flexibility. Could something else be written that consumes a simplified 
configuration but still produces, internally, the needed objects? Sure. 
Would I want to get rid of what exists now? No, it's powerful.

> And since we don't have the support, like you say, in app dial for
> multiple-level forking, I think the ability to register multiple
> phones to one aor is something we should disable until it works. It
> will just generate confusion and a long list of bug reports for Rusty
> to handle.

I've had multiple people from different places comment on this 
functionality and even after explaining the limitations and how to do it 
they still want it. I think disabling it just because it doesn't fit 
every need immediately would turn away a group of people who are 
interested in giving us feedback. In the end if it doesn't fit a need 
right now then you are not forced to use it.

As well the only confusion I could see from it is how to use it, and the 
bug reports would be lack of functionality which we could use to make 
sure we cover all the bases when extending and improving it.

-- 
Joshua Colp
Digium, Inc. | Senior Software Developer
445 Jan Davis Drive NW - Huntsville, AL 35806 - USA
Check us out at:  www.digium.com  & www.asterisk.org