On Sat, 19 Feb 2011 16:58:49 +0000, tony sayer <firstname.lastname@example.org>
>Bit of an odd one this. One of our customers wants a phone line in right
>out in the middle of a long way away off Bt's or anyone's network!. As
>it happens we have a communications site am few miles away and can
>install an Ethernet microwave link between the Two places.
These are pretty reliable if you have line of sight and you can
engineer the link to be reliable with low error rate.
Poor links will cause problems for data as well - the threshold for
reasonable VoIP is supposed to be less than 1%, and voice compression
makes the traffic more sensitive to drops.
0.1% or better is a good target.
>Customer wants that line and number to appear the remote location so I
>suppose they could use Two ATA adapters one analogue side facing the BT
>line and the other going direct to the phone in use. So from BT line to
>ATA unit to Microwave link then to ATA thence back to Analogue line.
>The microwave link can be thought of as a very long CAT 5 cable;!.
Better to think of it as a link between switches - unless there really
is nothing else connected?
Note wireless or other WAN links may have internal bridges in the end
>Anyone done that or know if it would work ?.
i have run enterprise VoIP systems across Ethernet WAN links around
the UK, using various types of link, and including microwave.
The latency within the UK is usually at most a few mSec (should be
less than 20 mSec unless you have a really wierd link).
the ITU standard (forget which one) recommends less than 150 mSec
latency 1 way before you get degradation of the call - but that is
from "mouth to ear" so includes code / decode as well as network
latency. Depending on the codec + tuning you will have 50 mSec or so
in the code / decode.
You should use QoS on the boxes at the ends of the link so that the
VoIP gets priority.
if the Ethernet WAN has a built in bottleneck (say x Mbps of
bandwidth but presented on a 100 Mbps Ethernet port), then unless the
link can be set to prefer not to throw away your VoIP (via 802.1p or
DSCP marking) then you need to shape the traffic so that nothing
overloads that bottleneck, so you control what gets through.
you should use a router or switch that can shape the overall traffic
flow, and then prioritise the VoIP within that. If the wireless link
is "wire speed" then you can just prioritise.
- replace xyz with ntl