It should come as no surprise that Asterisk loves to talk VoIP. But in order to do so, Asterisk needs to know which function it is to perform: that of client, server, or both. One of the most complex and often confusing concepts in Asterisk is the naming scheme of inbound and outbound authentication.
Connections that authenticate to us, or that we authenticate, are defined in the iax.conf and sip.conf files as users and peers. Connections that do both may be defined as friends. When determining which way the authentication is occurring, it is always important to view the direction of the channels from Asterisk’s viewpoint, as connections are being accepted and created by the Asterisk server.
A connection defined as a user is any system/user/endpoint that we allow to connect to
us. Keep in mind that a user
definition does not provide a method with which to call that user;
the user type is used simply to
create a channel for incoming calls.[117] A user definition
will require a context name to be defined to indicate where the
incoming authenticated call will enter the dialplan (in
extensions.conf).
A connection defined as a peer type is an outgoing connection. Think of it this way:
users place calls to us, while we place calls
to our peers. Since peers do not place calls to
us, a peer definition does not
typically require the configuration of a context name. However,
there is one exception: if calls that originate from your system are
returned to your system in a loopback, the incoming calls (which
originate from a SIP proxy, not a user agent) will be matched on the
peer definition. The default context should handle these
incoming calls appropriately, although it’s preferable for contexts
to be defined for them on a per-peer
basis.[118]
In order to know where to send a call to a host, we must know
its location in relation to the Internet (that is, its IP address).
The location of a peer may be defined either
statically or dynamically. A dynamic peer is
configured with host=dynamic
under the peer definition heading. Because the IP address of a
dynamic peer may change constantly, it must register with the
Asterisk box to let it know what its IP address is, so calls can
successfully be routed to it. If the remote end is another Asterisk
box, the use of a register
statement is required, as discussed below.
Defining a type as a friend
is a shortcut for defining it as both a user and a peer. However, connections that are both a
user and a peer aren’t always defined this way,
because defining each direction of call creation individually (using
both a user and a peer definition) allows more granularity
and control over the individual connections.
Figure 8-2 shows the flow of authentication control in relation to Asterisk.
A register
statement is a way of telling a remote peer where your Asterisk
box is in relation to the Internet. Asterisk uses register statements to authenticate to
remote providers when you are employing a dynamic IP address, or when
the provider does not have your IP address on record. There are
situations when a register
statement is not required, but to demonstrate when a register statement is
required, let’s look at an example.
Say you have a remote peer that is providing DID services to you. When someone calls the number +1-800-555-1212, the call goes over the physical PSTN network to your service provider and into its Asterisk server, possibly over its T1 connection. This call is then routed to your Asterisk server via the Internet.
Your service provider will have a definition in either its
sip.conf or iax.conf
configuration file (depending on whether you are connecting with the
SIP or IAX protocol, respectively) for your Asterisk server. If you
receive calls only from this provider, you would define them as a user
(if it was another Asterisk system, you might be defined in its system
as a peer).
Now let’s say that your box is on your home Internet connection,
with a dynamic IP address. Your service provider has a static IP
address (or perhaps a fully qualified domain name), which you place in
your configuration file. Since you have a dynamic address, your
service provider specifies host=dynamic in its configuration file. In
order to know where to route your +1-800-555-1212 call, your service
provider needs to know where you are located in relation to the
Internet. This is where the register statement comes into use.
The register statement is a
way of authenticating and telling your peer where you are. In the [general] section of your configuration
file, you place a statement similar to this:
register => username:secret@my_remote_peer
You can verify a successful register with the use of the
iax2 show registry and sip show registry commands at the Asterisk
console.
[117] In SIP, this is not always the case.
If the endpoint is a SIP proxy service (as opposed to a user
agent), Asterisk will authenticate based on the peer definition, matching the IP
address and port in the Contact field of the SIP header
against the hostname (and port, if specified) defined for the
peer (if the port is not specified, the one defined in the
[general] section will be
used). See the discussion of the SIP insecure option in Appendix A for more on this subject.
[118] For more information on this topic, see the discussion of
the SIP context option in
Appendix A.
Get Asterisk: The Future of Telephony, 2nd Edition now with the O’Reilly learning platform.
O’Reilly members experience books, live events, courses curated by job role, and more from O’Reilly and nearly 200 top publishers.
