[asterisk-dev] What's an AOR?

[Olle E. Johansson]

24 maj 2013 kl. 00:30 skrev Matthew Jordan <mjordan at digium.com>:

> 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.
So, from a SIP standpoint, what's the "mark" object below? Please explain.

>> 
> 
> 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."
Yes, like we do with "friend" now. It's not the config framework, but 
that doesn't matter.

> 
> 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?
First I think we need to reach an agreement on the levels of objects, I still haven't
got an explanation of the "type=endpoint" that makes sense to me. If it's just
a grouping like in the dahdi channel, we should call it "group". I am really afraid
of us implementing a user-type object in a channel driver, even though many
people ask for it. They ask for a solution, and we need to deliver something
that fits the Asterisk architecture and provide that solution. We should not be
forced to deliver it in the way the ask for it. We're still a multiprotocol PBX,
not a SIP pbx. Even though I would like for that change to happen ;-)

To answer your question, just go back through my mails and all the way back
to codename pineapple:
http://www.codename-pineapple.org/newtypes.shtml

Phone, service, trunk


> 
>>> 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.
Then we need to make sure that we do it in a way that doesn't break
the rest, because that will lead to a lot of bad feedback.

We can surely have a lab release for people to play with, but we have
released far too much experimental code in both LTS and normal releases
that stayed experimental through the years. 
How many releases have we had with the still experimental and buggy
TLS support in chan_sip.c? 

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

Don't parse me wrong here, I think you've made a lot of good work in the
SIP channel. It's a huge project and a considerable investment by Digium.
I am very grateful for that to happen and anxious that this is received
in a good way. Confusing people is not a good start.

/O