Voip相关

giant1st 发表于 2011-12-22 08:53

From： <a href="http://www.voipplanet.com/backgrounders/article.php/3495186" target="_blank" target="_blank">http://www.voipplanet.com/backgrounders/article.php/3495186</a> Who Sets the Standards for VoIP? 
March 22, 2005 
By <a href="http://www.voipplanet.com/feedback.php/http://www.voipplanet.com/backgrounders/article.php/3491911" target="_blank" target="_blank">Mark A. Miller</a> 
Voice over Internet Protocol (VoIP) networks combine the best of
voice and data communications networking technologies. But that combination
also creates some challenges, as the industry attempts to meld the best
of circuit switching (from the voice side) and packet switching (from
the data side) into single technology.

Perhaps the biggest challenge for network managers comes in the
area of multivendor interoperability—the concept that allows hardware
and software from different vendors to be integrated into a cohesive
system. But since vendors typically approach each other from a
competitive, rather than collaborative point of view, some neutral
parties are required to referee these interactions. Enter the standards bodies, internationally recognized groups whose purpose is to define and document implementation rules, called standards.
Networking standards are typically developed by a committee, which is
made up of interested parties, including inventors, developers, and
vendors, that have an interest in a specific technology. Most committees
are international in scope, and meet in person on a rather infrequent
basis—from every few months to every few years—to hash out（費力地去做） major issues,
but rely heavily on online collaboration for most of their research.

Two key groups produce standards that influence VoIP technologies. The first is the <a href="http://www.itu.ch/" style="text-decoration:none" target="blank" target="_blank">International Telecommunications Union</a>,
or ITU, which is headquartered in Geneva, Switzerland. The ITU's work
dates back to the 1860s when agreements were developed to support
connections between individual country's telegraph facilities.

As new technologies—radio, television, satellite, digital
telephony, and now VoIP—have emerged, the ITU has expanded and grown. At
the present time, the ITU's work is divided into three sectors: the
Radiocommunication Sector (called ITU-R), which manages the available
wireless spectrum; the Telecommunication Standardization Sector (ITU-T),
which develops internationally-agreed upon networking standards; plus
the Telecommunications Development Sector (ITU-D), which endeavors to
make modern telecommunications services available to people in
developing countries. ITU-T efforts have produced many international
networking standards, including Integrated Services Digital Network
(ISDN) and Asynchronous Transfer Mode (ATM), with a focus on wide area
networking technologies (harkening back to their early days in
international telegraph interconnections.). ITU-T standards are
designated by a letter, which identifies a specific area of technology,
followed by a series of numbers which identify the particular standard.
For example, standards beginning with the letter H deal with audiovisual
and multimedia systems, including VoIP. One of the often-quoted VoIP
standards in this area is H.323, titled Packet-based Multimedia Communications Systems. ITU-T standards are available online from the ITU-T.

The other key player in the VoIP standards world is the worldwide <a href="http://www.isoc.org/" style="text-decoration:none" target="blank" target="_blank">Internet Society</a>.
The Internet Society has served as the global clearinghouse for
Internet-related technologies since 1992, and as such is substantially
younger than the ITU. This age difference causes a difference in focus
as well—where the ITU has a rich history in circuit switched communications, such as voice, the more youthful ISOC concentrates more on packet switching and data transmission.

Like the ITU, however, the ISOC parcels its work into smaller
groups, including the Internet Architecture Board (IAB), the Internet
Research Task Force (IRTF), the Internet Engineering Steering Group, and
the Internet Engineering Task Force (IETF). The <a href="http://www.ietf.org/" style="text-decoration:none" target="blank" target="_blank">IETF</a>
is responsible for developing and publishing Internet Standards, which
are called Request for Comments, or RFC documents. RFCs begin as draft
documents from a specific Working Group, and after extensive review and
approvals are assigned a number, and then made available online by the <a href="http://www.rfc-editor.org/" style="text-decoration:none" target="blank" target="_blank">RFC Editor</a>.
Example RFCs would include the Internet Protocol (IP), RFC 791;
Transmission Control Protocol (TCP), RFC 793, the Hypertext Transmission
Protocol (HTTP), RFC 2616, and the Session Initiation Protocol (SIP),
RFC 3261.

Other organizations may also influence VoIP standards, but with a
more regional or technology-specific focus. These include: the <a href="http://www.ansi.org/" style="text-decoration:none" target="blank" target="_blank">American National Standards Institute</a> (ANSI); the <a href="http://www.etsi.org/" style="text-decoration:none" target="blank" target="_blank">European Telecommunications Standards Institute</a> (ETSI); the <a href="http://www.w3c.org/" style="text-decoration:none" target="blank" target="_blank">World Wide Web Consortium</a> (W3C); and the <a href="http://www.imtc.org/" style="text-decoration:none" target="blank" target="_blank">International Multimedia Teleconferencing Consortium</a> (IMTC).

In summary, an understanding of the underlying standards should
help network managers sort through the various systems and products that
they are considering for VoIP deployment on their network. Products
that adhere to ITU-T standards, such as H.323, are most likely to have
originated from a telephony and circuit switching perspective.
Conversely, products that adhere to IETF standards, such as SIP, are
most likely to have originated from the data and packet switching side
of the house. Both are quite workable, but approach technical issues
such as connection setup/disconnect in different ways. Adopting an
architecture that leans in one standards direction or the other,
however, can help focus all product decisions down the same road, and
thus bypass some of the interoperability challenges that you would
prefer to read about, rather than experience first hand.

Copyright © DigiNet Corporation ®. All rights reserved

The next article in this ongoing series, Fundamentals of Voice over
IP, will deal with some technical challenges relating to TCP/IP as a
transport platform for voice. Subsequent articles will examine
properties of specific protocols and deployment issues.
 篇二： Why TCP/IP Is not Sufficient for VoIP 
April 5, 2005 
By <a href="http://www.voipplanet.com/feedback.php/http://www.voipplanet.com/backgrounders/article.php/3495186" target="_blank" target="_blank">Mark A. Miller</a> 
As we discussed in our <a href="http://www.voipplanet.com/backgrounders/article.php/3491911" style="text-decoration:none" target="_blank" target="_blank">first Fundamentals of VoIP tutorial</a>（就是我们的篇一）, Voice over Internet Protocol (VoIP) networks combine both voice and data communications networking technologies. The combination
is somewhat like a marriage, in which two unique systems endeavor to
create some type of synergistic (and hopefully, peaceful) coexistence.
But as many of us have discovered, figuring out the strengths and
weaknesses of each member is a key making that partnership work; the
same is true for the voice and data "marriage" as well. Let's look at
the defining characteristics of each element in this VoIP partnership.

The connection-oriented/connectionless dichotomy 
Traditional voice networks are classified as connection-oriented networks,
in which a path from the source to destination is established, prior to
any information transfer. When the end user takes the telephone 
off-hook【摘机】, they notify the network that service is requested. The network
then returns dial tone, and the end user dials the destination number.
When the destination party answers, the end-to-end connection is
confirmed through the various switching offices along the path. When the
conversation is complete, the two parties hang up, and their network
resources can be re-allocated for someone else's conversation.

One of the disadvantages of this process is the consumption of resources spent setting up the call (a process called signaling,
which we will consider in a future tutorial). One of the advantages,
however, is that once that call has been established, and a path through
the network defined, the characteristics of that path, such as
propagation delay, information sequencing, etc. should remain constant
for the duration of the call. Since these constants add to the
reliability of the system, the term reliable network is often used to describe a connection-oriented environment. The Transmission Control Protocol (TCP) is an example of a connection-oriented protocol.

In contrast, traditional data networks are classified as connectionless networks,
in which the full source and destination address is attached to a
packet of information, and then that packet is dropped into the network
for delivery to the ultimate destination. An analogy to connectionless
networks is the postal system, in which we drop a letter into the
mailbox, and if all works according to plan, the letter is transported
to the destination. We do not know the path that the packet (or letter)
will take, and depending upon the route, the delay could vary greatly.
It is also possible that our packet may get lost or be mis-delivered
within the network, and therefore not reach the destination at all. For
these reasons, the terms best efforts and unreliable are often used to describe a connectionless environment. The Internet Protocol (IP) and the User Datagram Protocol (UDP) are examples of connectionless protocols.

Recall from your Internet History 101 class, that the Internet
protocols, including TCP, IP, and UDP were developed in the 1970s and
1980s to support three key applications: file transfers (using the File Transfer Protocol, or FTP), electronic mail (using the Simple Mail Transfer Protocol, or SMTP), and remote host computer access (using the TELNET
protocol). All of these applications were data- (not voice-) oriented,
and were therefore based upon IP's connectionless network design.
Layering TCP on top of IP gave the entire system enhanced reliability
(albeit with additional protocol overhead), but the rigors of a true
connection-oriented, switched infrastructure (like the telephone
network) was not necessary to support these applications.

Teaching an old dog new tricks 
Fast forward a few decades to the new millennium where visions of voice, fax, and video over IP dominate. These applications are sensitive to sequencing and delay issues, and the idea of a "best efforts" service—especially if the voice conversation must go through, such as a call to the police or fire department—will not gather many supporters.

Which brings us to the challenging question: How do we support connection-oriented applications (such as voice and video) over a connectionless environment
(such as IP), without completely redesigning the network
infrastructure? The solution is to enhance IP with additional protocols
that fill in some of its data-centric gaps. These include:
<ul><li>Multicast Internet Protocol (Multicast IP), defined in RFCs 1112 and 2236. Multicast allows information from a single source to be sent to multiple destinations (as may be required for conferencing).
</li><li>Real-time Transport Protocol (RTP), defined in RFC 3350. RTP provides functions such as payload identification, sequence numbering, and timestamps on the information.
</li><li>RTP Control Protocol (RTCP), also defined in RFC 3350. RTCP monitors the quality of the RTP connection.
</li><li>Resource Reservation Protocol (RSVP), defined in RFC 2205. RSVP requests the allocation of network resources, to assure adequate bandwidth between sender and receiver.
</li><li>Real-Time Streaming Protocol (RTSP), defined in RFC 2326. RTSP
supports the delivery of real-time data, including retrieval of
information from a media server or support for conferencing.
</li><li>Session Description Protocol (SDP), defined in RFC 2327. SDP
conveys information about the media streams for a particular session,
including session name, time the session will be active, what media
(voice, video, etc.) is to be used, the bandwidth required, and so on.
</li><li>Session Announcement Protocol (SAP), defined in RFC 2974. SAP packets are periodically transmitted to identify open sessions that may be of interest to the end user community.
 Copyright (C) 2005 DigiNet (R) Corporation
</li></ul>

So is TCP/IP adequate for VoIP? Strictly speaking no, but with the
addition of new protocols to support time sensitive applications such as
voice and video, the existing IP infrastructure can therefore be all
things to all people—supporting both connection-oriented and
connectionless applications. In the next several tutorials we will
examine some of these new protocols in more detail.


Author's Biography 
Mark A. Miller, P.E. is President of DigiNet (R) Corporation, a
Denver-based consulting engineering firm. He is the author of many books
on networking technologies, including Voice over IP Technologies, and Internet Technologies Handbook, both published by John Wiley & Sons.

页: [1]

Chinaunix's Archiver

Voip相关