![Terayon TA-102 Скачать руководство пользователя страница 66](http://html.mh-extra.com/html/terayon/ta-102/ta-102_technical-support-manual_1088579066.webp)
Chapter 4 PacketCable Network Architecture
Placing a Call in a PacketCable Network
4-10
TA 102/202 Technical Support Guide
Placing a Call in a PacketCable Network
If you have read the “PacketCable Network Architecture” and “PacketCable Functional
Components” sections, you have a pretty good understanding of the hardware and
software applications involved in a PacketCable network. But, what really happens
when someone makes a simple phone call?
To answer the question, the following paragraphs examine the process of making an
ordinary phone call on a packet based network. We’ll keep it simple and ignore a lot of
the details, but, hopefully you’ll get an idea of what goes on during a phone call.
To explain a PacketCable phone call, we have developed a simple example call. Figure 4-
8 provides a summary of the simple example.
Imagine for a moment a cable operator (ACE Cable Company) and two callers, Athena
and Brad. ACE Cable Company has all the equipment required to offer subscribers
PacketCable telephony and Athena and Brad are subscribers. Athena decides to call
Brad to ask questions about the project they are working on. Athena’s phone is con-
nected to an embedded MTA, in other words, a cable modem and a Multimedia Terminal
Adapter in the same box. The phone she is about to use is simply an I/O portion of the
MTA.
When Athena lifts the phone, she hears a dial tone. But this dial tone is not coming from
the phone company central office — it is being generated by the MTA her phone is con-
nected to. Athena dials Brad’s phone number. On a regular PSTN phone line, each digit
is sent to the central office as it is dialed. A switch in the central office collects the digits
and checks after each digit to see if an entire phone number has been dialed.
On the ACE Cable Company PacketCable Network, things are very different. Instead of
each digit being sent as dialed, the MTA collects the digits, but sends no signals to the
network until Athena presses the last digit. Athena’s MTA (we’ll call it MTA
A
) has an
internal digital map that tells it when Athena has dialed a complete number. As she
presses the final digit, the MTA recognizes a complete valid phone number and then
builds a UDP packet.
The UDP packet contains information about itself and the number Athena dialed, along
with the destination IP address of Brad’s Call Management Server (CMS
B
). MTA
A
transmits the UDP packet to Athena’s CMTS
A
which acts as a router and forwards the
packet to CMS
A.
CMS
A
decodes the packet and checks to see if Athena is a paid-up sub-
scriber. When CMS
A
verifies Athena is a legitimate caller, it consults a data base to
determine the identity of the Call management Server (CMS
B
) that serves Brad’s phone.
CMS
A
now contacts CMS
B
informing it that Brad has an incoming call. It also sends a
message to CMTS
A
, telling it to reserve enough bandwidth on the HFC network to
ensure call quality. When CMS
B
receives the news that Brad has an incoming call, it
contacts CMTS
B
and instructs it to reserve bandwidth for the incoming call to Brad.