|
Actual
VOIP/SIP Implementations:
Before your “cutover” date, AT&T will have
installed/tested the internet circuit and router and provided the customer
with their “Information Packet” here is a redacted
example. This document has the IP addresses to reach the AT&T
system (they call them “border elements”) Circuit ID for the internet
circuit and a whole host of other information you won’t need or be able to
make sense of (keep it for the IP addresses and circuit ID).
If you
are adding the AT&T service to your existing network as a secondary
gateway device you will need to give the AT&T tech a static
address/mask in your LANs range to assign to the Cisco router/gateway. He
will also need to know the address of your Asterisk server (these two
addresses must be in appropriate LAN segments to be able to communicate).
Then reconfigure the NIC on your Asterisk server to use the IP address you
gave to the AT&T gateway LAN port as its default gateway. This makes
your server go through AT&T every time it goes to an outside address…
in particular when it sends a call to the AT&T “border elements” (IP
addresses) so your outbound calling is ready to go. As for inbound calling,
that is up to the AT&T tech and why he asked for the address of your
server. AT&T delivers the calls to the outside address of the Cisco
router they installed and the tech puts a rule in place in that router to
deliver calls to your server.
Create
two trunks (one using each of the “Border Elements” AT&T assigned) with
both outgoing and incoming peer settings like this;
You don’t
need to enter any registration string the SIP trunk from AT&T doesn’t
use any credentials other than IP addresses and router ID. The incoming
settings part is primarily to identify the incoming calls as permitted so
you can leave your “Allow Anonymous Calls” system setting to “No” and also
for tracking purposes in the logs. The settings shown reflect what I have
had best luck with regarding DTMF and reliable hand-off.
Of course you will still need to create
appropriate inbound and outbound routes depending on how AT&T will be
delivering DID (DNIS) info and accepting outbound calls (usually on
outbound they require a minimum of 10 digits including area code). At this
point you will begin testing with the AT&T tech and everything may just
work fine… it has happened that way for me twice in nine implementations.
If it doesn’t, look in the section below; “Things I have had to do to
get it to work”
Now for
a more challenging implementation. One in which for some reason you need to
keep the Asterisk server pointed to the original network gateway and add a secondary gateway to its
routing table. This might be because the AT&T tech tells you “we are
not allowing internet access via the Cisco gateway due to policy”… when you
hear “policy” from an AT&T tech, just give up and start looking for a work-around,
even if this policy doesn’t match the last four times you have done the
exact same thing… you won’t overcome it.
This
happened in the last implementation I did and the Asterisk server needed to
see the internet to send voice-mail-to-email, access a remote NTP system,
get system updates and, of course, be accessed remotely for system support.
None of which was going to happen through the new AT&T circuit… only
VOIP calls… “policy”. In that case the customer
was also separating the phone sets onto one V-LAN and data access onto
another, so we needed to have the server access both. That allowed the
phones to attach and users to access the ARI (user/voicemail) GUI and also
administrative access to the server.
So,
dual gateways on the same Linux server… a WARNING here; Centos will allow you to add a second default
gateway on a server, it looks like this:
And it screwed things up royally. Calls didn’t
know which gateway to use outbound and the system started running erratically
and crashed… YOU SHOULD NOT DO THIS. From the guy who did it…
In the above
example (which I copied live from a system I was implementing AT&T IP
Flex on) the server had two NICs in two different IP ranges. One each for
two V-LANs; 1 and 5, Each NIC was connected to a dedicated V-LAN port on
the network switching system, V-LAN 1 being the data (192.168.1.xxx eth1)
and V-LAN 5 being the VOIP (192.168.5.xxx eth0). The LAN port on the
AT&T Cisco router was connected to a dedicated V-LAN 5 port (using an
appropriate static IP address) and the phones and PCs were connected to
V-LAN ports that defaulted to V-LAN 1 but delivered tagged V-LAN 5 packets.
The
phones actively pick up V-LAN 5 packets but route V-LAN 1 out their PC
ports… hence a phone could be plugged into a port, connect via V-LAN 5,
pick up its IP address in the appropriate range and connect to the Asterisk
server. A PC then could be plugged into the PC port of that same phone and
only see V-LAN 1, pick up its appropriate IP address and access the data
services/domain, etc.
The
answer to get this working correctly was to route outbound calls via the
AT&T “Border Elements” to a specific gateway on V-LAN 5. And the
commands that accomplished that in this case were:
One for each border element IP address range,
giving me a final route table that looked like this:
With the above configuration calls began to flow
in/out correctly.
------------------------------------
I
should warn you that the above two examples reflect only about four of the
implementations I have done and that there has been a wide variation in how
the different AT&T techs wanted to configure things on the Cisco
router/gateway. These include; “Solid firewall with nothing through but
VOIP from AT&T”, “wide-open with nothing blocked (Lock down your server!?!?!)” and
in one instance the tech required me to hand off outgoing calls to an IP
address within the Cisco that did not match its LAN or WAN address ranges or the border elements (I struggled
with that one).
So…. be
prepared to be “flexible”….
This is the AT&T document on
AT&T/Asterisk SIP Trunk Compatibility Testing that their techs will
often point you to. It does have some pertinent info in it, but is dated,
harkening back to Asterisk 1.4 from 2008
|
