[asterisk-users] Recommendations about infrastructure to use with Asterisk

[John A. Sullivan III]

On Thu, 2009-09-03 at 06:30 -0300, Daniel Bareiro wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Hi all!
> 
> I'm investigating the possibility of using Asterisk as much for internal
> communication in an office as between offices and I would like to know
> what considerations you could comment to me being based on the
> experience that you have had.
> 
> A priori two things come to my mind:
> 
> * As to network topology, is advisable to have switches and
>   dedicated networks for to use with the extensions?  
> 
> * Is advisable to have a dedicated Internet connection for
>   intercommunication between the different offices? I imagine that yes,
>   since of another way the VoIP traffic would have to compete with the
>   rest and in that case we would require to apply some additional
>   technique of QoS. In this point also I would include the optimal
>   bandwidth that would have to have the dedicated link, for the case of
>   using something of this type.
> 
> Perhaps there is some other interesting questions that also it is
> necessary to consider.
> 
> In order to give more additional information, the Internet connection
> between the different offices is made at the moment through two links of
> 2 Mbps, with load balance (one of fiber and another one of microwaves).
> The amount of extensions in one of the offices would be approximately of
> 50, whereas in the other there would be approximately about 80
> extensions.
<snip>
I'll begin by saying there are others on this list with much more
experience than I.  Given that reservation, it is the unending balance
between cost and performance.

It would be ideal to have two separate networks if it is affordable.
Integration between the PBX and the data network, e.g., integrating
voice mail and email, can be done via a separate interface on the PBX.

There are challenges in using the Internet for inter-office
connectivity.  Better to use a private WAN or Internet connections with
a single carrier who will honor Class of Service settings.  Once one
dumps one's traffic onto the Internet, there are no guarantees that real
time traffic will be prioritized over bulk traffic.  Since the greatest
point of congestion is probably the last mile, you may be able to make a
creative deal with your carrier to implement CoS at your upstream
router.  That will prioritize ingress traffic turning off the
"super-highway" and onto your "back road".  Likewise, you can implement
CoS on your Internet gateway to prioritize egress traffic.

These prioritization methods can help not only your inter-office traffic
flow but can also be used if you cannot afford separate internal
networks.  We implemented CoS in our switches and chose settings on the
end points to take advantage of the defaults settings for our Linux
gateways and devices.

Specifically, our end points set the DSCP bits to 101100 rather than
101110 (expedited forwarding) - b0 instead of b8 in Asterisk, 176
instead of 184 in Snom, 44 in iptables.  This is because the Linux
default pfifo-fast packet queueing looks at a different set of bits in
the same TCP field and consequently places 101110 in a lower priority
queue (band 1 I believe - the default band) than 101100 (I believe band
0).

We set our switches to map packets with DSCP 101100 into the highest
priority queue.

We elected not to change our MTU to 576 (typical default is 1500) but
this improves quality on highly congested lines.  The voice packets may
be prioritized but, if a big packet sneaks in while the voice queue is
momentarily empty, it may take a while to transmit depending on the
bandwidth of the link.  You should not implement jumbo packets on a
shared network for this reason.

You may also have some security considerations in a shared network.  We
have found that connection tracking / stateful inspection support is
spotty for SIP traffic.  This is especially true if you set
canreinvite=nonat or yes to try to shift the media stream away from
Asterisk and to the end devices.  We have found that most of the
conntrack mechanisms do a good job tracking the shift from the SIP port
to the RTP port when the call is passing through Asterisk.  Some
struggle when Asterisk reinvites the call.  We haven't tracked it down
but it appears that iptables takes about 30 seconds to kick in - we
suspect it does not make the proper association until there is a SIP
exchange between the new end points but we have not confirmed that.
Even if we get around that problem, we have a bigger mess if one end
point speaking directly with another end point transfers the call.

The option is to allow access no only to the SIP port but to some or all
high UDP ports.  We were very unhappy with that arrangement but, after
struggling unsuccessfully to have iptables pick up these transfer
scenarios, we opted for a compromise where we open up the high UDP ports
to hard phones but do not for soft phones since we do not want to expose
any user applications which also happen to be listening on high UDP
ports to attack.  Oh, I should mention we use the ISCS project
(http://iscs.sourceforge.net) to restrict all network traffic on an
as-needed basis - firepiping instead of firewalling - hence the concern
that we want to restrict network access even on the internal networks.
As a result, hard phones are canreinvite=nonat and have UDP high ports
open whereas soft phones are canreinvite=no and do not allow access to
UDP high ports unless associated with an initial SIP conversation.

This is certainly a big topic but I hope this gives you some place to
start.  It is what we did and we are please so far with our results in
test.  We will stress test this implementation in production this coming
week.  Good luck - John
-- 
John A. Sullivan III
Open Source Development Corporation
+1 207-985-7880
jsullivan at opensourcedevel.com

http://www.spiritualoutreach.com
Making Christianity intelligible to secular society