[asterisk-dev] What's an AOR?

[Matthew Jordan]

On 05/24/2013 01:59 AM, Olle E. Johansson wrote:
> 
> 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>

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

I'm going to focus on this part of the discussion :-)

Here's a very preliminary proposal for how phone and trunk would map to
the existing objects:

-- Phones --

Requirements for phones:
 * Asterisk acts as a registrar
 * Asterisk acts as a notifier for MWI/device state
 * Authentication/AoR/Endpoint details subsumed within 'phone' config
 * Additional configuration options possible using existing association
references

Phones automatically create three of the existing configuration objects:
endpoint, auth, and aor. The settings in endpoint, auth, and aor are
inherited from the settings obtained in the configuration section for
the phone. Where settings can be configured either on an endpoint or on
an associated object - such as mailboxes - the settings are configured
on the associated object (we expect the phones to subscribe for MWI,
device state, etc.)

Note that because phones register, we don't have to provide an
identification service. Anonymous access, non-registering phones, etc.
would require additional configuration beyond the default phone object.

aor is configured with some default max_contacts (say, 10).

Example:

[matt]
domain=foo.com
type=phone
context=default
force_report=true
direct_media=true
mailboxes=1000 at default
send_rpid=true
disallow=all
allow=ulaw
username=matt
password=secret

=>

[matt at foo.com]
type=endpoint
context=default
force_report=true
direct_media=true
send_rpid=true
disallow=all
allow=ulaw
auth=matt at foo.com
aors=matt at foo.com

[matt at foo.com]
type=auth
username=matt
password=secret

[matt at foo.com]
type=aor
max_contacts=10

If, however, we wanted ACLs, we would still have to reference them as a
separate object. So something like this:

[matt]
type=phone
...
acl=my_phone_acls

[my_phone_acls]
type=acl
deny=0.0.0.0/0.0.0.0
permit=10.24.11.0/255.255.255.0

(Note: ACL support isn't quite done yet, so you won't see an acl option
for endpoints just yet :-) )

-- Trunk --

Requirements for trunks:
 * Asterisk identifies outbound/inbound traffic based on a specific location
 * Asterisk can optionally authenticate (via whatever mechanism)
inbound/outbound traffic
 * Authentication/AoR/Endpoint/Identity details subsumed within 'trunk'
config
 * Additional configuration options possible using existing association
references

Identification is the big thing here - we can identify requests based on:
 * Sets of IP addresses
 * User at domain name

This does mean we can't *currently* look up a hostname and - when we are
'supposed to' - resolve that to a set of IP addresses. This could be
done as a new identification service that wraps around the IP
identification services.

Authentication can also occur both ways. Normally this would be set up
using two authentication objects; here, outbound authentication settings
are prefixed with 'outbound_'.

Note that the example below uses 'standard' username/password for
authentication. Authentication could also be set up using realms,
prefixed with 'outbound_' for outbound authentication.

Example:

[my-service-provider]
type=trunk
context=default
disallow=all
allow=ulaw
direct_media=false
match=123.456.789.100
match=123.456.789.101
match=123.456.789.102
match=123.456.789.103
outbound_username=matt
outbound_password=secret
username=my-service-provider
password=their-secret

=>

[my-service-provider]
type=endpoint
context=default
disallow=all
allow=ulaw
direct_media=false
aors=my-service-provider
outbound_auth=outbound-my-service-provider
auth=inbound-my-service-provider

[my-service-provider-identity]
type=identity
match=123.456.789.100
match=123.456.789.101
match=123.456.789.102
match=123.456.789.103
endpoint=my-service-provider

[my-service-provider]
type=aors
contact=sip:123.456.789.100
contact=sip:123.456.789.101
contact=sip:123.456.789.102
contact=sip:123.456.789.103

[outbound-my-service-provider]
type=auth
username=matt
password=secret

[inbound-my-service-provider]
type=auth
username=my-service-provider
password=their-secret

-- Services --

I'm a little ambivalent about this particular type - wherein Asterisk
acts as a phone, performing outbound registration, outbound
subscriptions, and other phone-ish activities. From the "Asterisk is a
PBX" perspective, this feels like a rather rare use case which could be
expressed using the existing objects. I'm not sure we'd get a lot of
mileage out of defining a higher level of abstraction - but I could be
wrong. For now, I'll punt on it since it's significantly odder than
'phones' or 'trunks'.

Discussion/flames welcome :-)

Matt

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