Nothing sells VoIP like a woman on a telephone

It's an epidemic of conventionality: it seems like every company who's ever tried to sell something related to VoIP uses, at some point, a photo of a woman holding a telephone.

Proof by Numerous Examples:

Genisys:

Broadcore:

XO Communications:

From Sprint:

AT&T:

Covad:

From Level(3) (She's using a SIP Soft Client, of course):

From PhoneOverNet:

VoIP RTP Packetization Interval: Maybe it's time for a smaller ptime

When a one vendor's VoIP media/trunking gateway is talking to another
of the same type, it uses 5 ms packetization (ptime) by default. I.e.,
each RTP packet has only 5 ms of audio recorded in it. At first this
sounds crazy. The efficiency is awful! The bandwidth across Ethernet
for G.711 goes to 188 kbps per call per direction! It also means that
a single call imposes 400 packets per second (PPS) on a router along
the path.

20 ms packetization is "normal". But consider one bane of VoIP
providers: echo. The greater the delay between when I talk and when I
hear myself, the more annoying the echo is.

The ptime contributes to the delay. In the best case, total echo delay
due to VoIP will be 2*ptime+rtt, where rtt is the round-trip time
across the IP and TDM networks from one VoIP endpoint to the other.

A typical jitter buffer size is 3*ptime, as well. Since there are two
jitter buffers, that adds 2*3*ptime to the echo delay.

All added together, the echo tail duration could be 8*ptime+rtt.

With the standard 20 ms ptime, and an engineered network with 30 ms
network RTT, my echo tail length could be 190 ms. Imagine talking in
an room with hard walls, floors, and ceilings, 106 feet across. You'd
hear yourself echo back.

If we drop this to 5 ms ptime, we drop the talker-echo delay to 70 ms.
Now the echoey room size has dropped to 39 feet across, and you
probably don't really notice that echo. But we significantly increased
the requirements of the network -- four-fold increase in PPS, and 200
kbps increase in bandwidth per call.

Now let's throw in a brand-new Foundry MLX network with 10-Gigabit-
Ethernet pipes and 2-Billion PPS capacity. Now what do you think about
188 kbps / call?

Private IP Addresses in VoIP Networks Considered Harmful: Sloppiness

Over the past few years, it's become very common for VoIP carriers
(i.e., telephone companies using VoIP) to use private (RFC 1918) IP
addresses in their internal VoIP network. These have IPs like
192.168.0.1 or 10.0.0.1. This practice has been promoted by many of
the hardware vendors. It reflects the setup many of them use in their
labs.

There are a number of problems this creates. One of the biggest
problems is really a human problem: people aren't nearly as careful
with private IP address space as they are with public Internet IP
addresses. So in several cases, including some very large firms,
they've accidentally re-used the same IP addresses on two different
networks.

The result is that the two different networks can't reach each other;
nor can you route through one of them to the other.

Every technical problem is, in a way, a human problem. The human part
of this is just outright sloppiness and laziness. In this case,
there's nothing fundamentally wrong with the private IPs -- it's the
way the people are using them. Private IPs are traditionally used in
home networks and small-office networks. They're used very informally.
In many cases, a home or office network of private IP addresses can be
re-numbered easily by changing the DHCP server.

In VoIP networks, though -- as in all server networks -- renumbering
is a big deal. DNS should aid in renumbering. But many VoIP devices
don't really use DNS to find each other -- they use IP addresses, and
don't support DNS lookups. (The reasons for this appear to be a lack
of faith in reliable DNS operation, and a tradition of using numeric
point codes in the SS7 network.)

VoIP is hard enough as it is. Carrier VoIP is harder than enterprise
VoIP. Bringing along the whole mentality of slap-'em-on-there private
IPs just doesn't help anybody.