Chinaunix首页 | 论坛 | 博客
  • 博客访问: 761922
  • 博文数量: 230
  • 博客积分: 6330
  • 博客等级: 准将
  • 技术积分: 2188
  • 用 户 组: 普通用户
  • 注册时间: 2009-07-10 15:55
个人简介

脚踏实地

文章分类

全部博文(230)

文章存档

2017年(1)

2016年(7)

2015年(10)

2014年(32)

2013年(24)

2012年(33)

2011年(50)

2010年(30)

2009年(43)

分类: 网络与安全

2011-07-10 11:08:45

 From:


Who Sets the Standards for VoIP?
March 22, 2005
By

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 , 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 . 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 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 . 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 (ANSI); the (ETSI); the (W3C); and the (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

As we discussed in our (就是我们的一), 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:

  • 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).
  • Real-time Transport Protocol (RTP), defined in RFC 3350.
    RTP provides functions such as payload identification, sequence numbering, and timestamps on the information.
  • RTP Control Protocol (RTCP), also defined in RFC 3350.
    RTCP monitors the quality of the RTP connection.
  • Resource Reservation Protocol (RSVP), defined in RFC 2205.
    RSVP requests the allocation of network resources, to assure adequate bandwidth between sender and receiver.
  • 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.
  • 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.
  • 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

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.

阅读(799) | 评论(0) | 转发(0) |
给主人留下些什么吧!~~