[asterisk-dev] What's an AOR?

[Olle E. Johansson]

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. 

To have both mark and mark-aor in the same name space is confusing and I don't really agree with the use-case (multiple line phone). 

Now, if we're discussing SIP-outbound or dual stack phones, you will get multiple contacts for the same endpoint - but they all point to the same device. Then we need logic to choose one and place the call. So multiple contacts for one account is something we need, but for one device.


I don't really see the point of having one [olle] and multiple [olle-aor]. Seems to me like you are inventing yet another "user" object, which we should do, but not in the SIP channel. It's the wrong place for that kind of object. (and let's ignore users.conf... :-) )

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 have suggested a way to push multiple phones that register for the same account many times, so I won't reiterate. But with instance-id, this is simple and can be done without changing app_dial or hints or app_queue.

I am a stubborn old man, so bear with me when I still suggest that we need to come up with a configuration that use terminology that the world of SIP applications use and reflect how people want to use it. It's a very, very small group that will benefit from this complexity and wiki pages will not help - only easy-to-use software. Yes, we're not talking about end users, but we still need usability. With marketing language, we need this channel driver to be attractive and adopted quickly.

/O