[Cu-wireless] VoIP overview

[David Young]

I had a meeting the other day with Stephane Alnet about Voice over IP,
especially as it concerns wireless. Here is my summary. All mistakes
are mine.

Stephane explained that in any VoIP solution, there are two types
of traffic, "call signaling" (aka "call control") and the "bearer"
traffic. Call signaling is used to start/stop calls and signal conditions
like "line is busy."  Bearers carry voice/fax/modem/data traffic.

There are two major standards for VoIP. SIP is IETF's standard. It
is pretty new, with commercial implementations 2 years old or younger.
H.323 is a 10-year old standard by ITU. It comes in versions 1 through 4,
with 4 very much preferable. It is older, with commercial implementations
being around for 10 years.

One reason SIP is expected to prevail is its
featurefulness/buzzword-compliance.  It supports for "presence," i.e., the
notion that you might or might not have your cell phone on your person,
or you might want to take some class of calls at home, others at home
and on your cell, and so on. One "class" of calls might be those placed
by your employer, and another class, those placed by your family. (I am
guessing that there are classifications based on time and such, too.)
SIP has features for dealing with presence.

SIP encompasses call signaling and, using a protocol called SDP,
bearer-traffic negotiation. (Bearer-traffic negotiation is where the
endpoints of a VoIP call choose a codec and set other parameters for
the bearer channel.) In H.323, however, there are different protocols
for signal & bearer traffic. H.225 is the signaling protocol, and H.245
is the bearer-traffic negotiation protocol. Both SIP and H.323 bearer
traffic is carried by the Real-Time Protocol (RTP). RTP is an unreliable
datagram service for data that needs timely, constant-speed delivery
above all else.  RTP packets are embedded in UDP packets. For every RTP
stream in one direction, there is usually a Real-Time Control Protocol
(RTCP) stream in the opposite direction.  RTCP carries statistics on
percentage & rate of delivery back to the RTP source.

A SIP phone converts telephone numbers to (IP number, UDP port) pairs
using a "SIP proxy" device. An H.323 does the same using a "gatekeeper"
device which speaks a protocol called RAS.

The community wireless network should probably use SIP.

There are devices by Cisco and others for connecting a VoIP network to
the Public Switched Telephone Network (PSTN), aka "the Bell System".
One device, ATA-186, acts as a VoIP gateway to your FXO (Foreign eXchange
O...: fancy name for your two-wire phone outlet at home). The telco's
end of the pair is called the FXS, Foreign eXchange Startloop. This is
an analog connection to the PSTN. It's cheap, you've got one already.

You can make a digital connection to the PSTN using ISDN. There are a
few kinds of ISDN service. One is BRI, Basic Rate Interface. Provides
two bearers (64kb/s channels, where kb = 1000 bits, not 1024 bits, in
telco-speak) and a control channel. It is not cost-effective to use
a BRI as your gateway to the PSTN.  Paying for up to 8 FXOs is more
cost-effective than buying a digital connection, actually. There is an
ISDN connection called a PRI, also expensive, that has 23 64kb/s bearers.
A T1CAS (E1/R2 is the equivalent in Europe) which also has 23 bearers,
is most cost-effective.

You can "roll your own" VoIP gateway using a modem.  There is
an open-source project, Bayonne, that is concerned with making PBXs
(business phone systems). They use some device that can "bond" eight FXOs.

There are a variety of codecs, which are essentially encodings for
voice. G.711 is the PSTN codec. It's not too fancy, works just fine
on a 64kb/s channel. There is also G.729, a 8kb/s codec, uses voice
recognition principles to compactly encode whole phonemes (e.g., the
"ay"-sound). An 8kHz sampling rate is standard for telephony codecs.

(Incidentally, G.729 traffic is 28kb/s on IP over Ethernet. Lots of
overhead, there!)

There is an art and science to figuring out how many trunk lines you
need to serve some number of households.

The routers and other equipment on your IP network need to provide good
quality of service (QoS) to the RTP packets that carry your IP phone
calls, or else your users will be frustrated, both as they place calls
and especially during conversations. Typically a router will put the RTP
packets onto a high-priority or low-latency queue. 802.11 networks have
their own special problems with quality of service. 802.11e is a task
group concerned with QoS extensions to 802.11, but they have not issued
a final standard. (I think WECA---Wireless Ethernet Compatibility
Alliance---has produced a standard called Wireless Multimedia
Extensions---WME---which is a subset of the anticipated 802.11e standard.)

VoIP handsets are plug & play. They will automatically tftp a
configuration file from the VoIP gateway---which they discover using
DHCP? To "VoIP-enable" the community wireless network, it looks like it
may be necessary for each node to be able to bootstrap popular VoIP phones
and also to act as a SIP proxy. For truly "ad hoc" telephony, it will
be necessary for the nodes to provide a "distributed telephone book".
For PSTN-connected networks, we can probably rely on the PSTN gateway
to provide the phonebook centrally.

Dave

-- 
David Young             OJC Technologies
dyoung at ojctech.com      Urbana, IL * (217) 278-3933