[asterisk-dev] What's an AOR?

[Matthew Jordan]

On 05/23/2013 10:41 AM, Joshua Colp wrote:
> Olle E. Johansson wrote:
>> 23 maj 2013 kl. 16:48 skrev Mark Michelson<mmichelson at digium.com>:
>>

<snip>

>>
>> 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.
> 

I don't think we need to get rid of the configuration settings that are
currently available. They are powerful and let you configure things in
whatever way you want.

That being said, there's no question that it takes a bit to wrap your
head around the new settings - but that's often the case when you're
given something that has a lot more power than what you're used to. So,
I can see the need for configuration types that compose the basic
building blocks into other higher level entities. For example, take
Mark's endpoint, but add some authentication flavor to it, and make the
aor/auth types use the same name:

[mark]
type = endpoint
callerid = Mark <1234>
disallow = all
allow = ulaw
aor = mark
auth = mark
context = default

[mark]
type=aor
max_contacts=1

[mark]
type=auth
username=mark
password=bananas

I've found that I usually end up with something like this (albeit with a
lot of templating). It wouldn't take a lot for the configuration parsing
to collapse/expand another entity into that. For phones, you could just
as easily collapse this down into:

[mark]
type = phone
callerid = Mark <1234>
disallow = all
allow = ulaw
username = mark
password = bananas
context = default

The config framework could intercept objects of type phone, and say "oh!
This is really an endpoint named mark, with an aor and an authentication
object. I'll make those for you."

Now, if you need more flexibility, then you have two options:
1) Don't use type phone.
2) Alternatively, we could let contexts of [mark] with type=aor or
type=auth replace the objects that is created for phone.

Olle: what other 'high level' constructs would be useful? What rules
should be applied to the lower level objects for those higher level
constructs?

>> 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.

I agree with this. We know that there are some use cases people will
want to do with multiple devices registered to a single AoR that we
won't be able to do - namely anything involving fine grained control
over the device state. That sounds like an awesome new feature to work
in (maybe for 13, depending on how bad the core portions get)

If we don't expose any of it, however, I think we might be losing out on
fulfilling a number of valid use cases where people just want the
ability to have multiple devices register to the same AoR and to dial
them. That's been a huge feature request for quite awhile now, and I
think giving it to them is a good thing.

> 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.
> 

Well... bug reports are going to come in. We've got a *lot* of
documenting to do, including documenting the limitations of what we can
do with what is currently in the new SIP work.

-- 
Matthew Jordan
Digium, Inc. | Engineering Manager
445 Jan Davis Drive NW - Huntsville, AL 35806 - USA
Check us out at: http://digium.com & http://asterisk.org